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DETAILED ACTION 

Claims 1-98 have been examined. 

Claims 12, 18, 19, 20 , 21, 30, 54, 70 71, 72, 76, 77, 78,80 and 81 were amended in a preliminary 
amendment received February 5, 1999. 

, ^JDxamags. 

1. The corrected or substitute drawings were received on March 15, 1999. These drawings 
are approved by the Draft's Person. 

Information Disclosure Statement 

2. In the event the invention is related to the Assignee's (IBM) product FLOWMARK 
(IBM Trademark #2006543) the Applicant is reminded of their duty to disclose. FLOWMARK 
dates back to filing for Trademark on December 16, 1993. Date of first use in commerce June 
28, 1995. 

3. The Applicant makes specific reference to Object Management Group (OMG), the 
Assignee (IBM) is a long time member of this standards organization for Object technology. In 
the event work of OMG is relevant to Common Object Request Broker (CORBA), application 
frameworks and Business Objects, the Applicant is reminded of their duty to disclose. 

4. In the event, the invention is related to the tool ISMOD used by IBM in 1990 to model 
dimensions of business such as "data and information, data criticism, data flow identification, data 
flow metrics, data qualifiers, event triggers, location, organization, processes", as described in 
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IBM System Journal, Vol 29 Issue 4, page 509, page 17, then, the Applicant is reminded of their 
duty to disclose. 

5. In the event, the invention is related to the tool DevelopMate used by IBM in 1990 to 
develop a business/enterprise model with dimensions that include business processes, business 

.data-events... /l,-as-described_in.ffi^ 

the Applicant is reminded of their duty to disclose. 

6. In the event, the invention is related to the product of Newi from Integrated Objects - a 
joint venture of IBM and Softwright based in England, the Applicant is reminded of their duty to 
disclose. 

7. In the event, the invention is related to feature "rule editor probe", contained in the 
product Object Management Workbench (OMW) of Intellicorp, the Applicant is reminded of 
their duty to disclose. 

Currently, compliance with this request is only covered under 1 .56 but could be the subject of a 
future Requirement For Information (RFI) under 1 . 105. 

Specification 

8. The Specification contains and error on page 6. No case with the Serial number 

of 09/993,718 has been filed with the USPTO at this time. The correct serial number is needed as 
part of an amendment. 

Examiner's Interpretation 

9. The following are Examiner interpretations. 
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a. Modeling - The Martin book teaches the use of modeling an enterprise ( Martin, page 247 - 
249) operation and provides Appendix A, Recommended Diagraming Standards. Martin page 285 
illustrates the transition from the problem domain, to modeling, to 00 Design to code. The 
Martin reference has many chapters covering modeling and discusses the models are tied together 
-to-generatexode (Martin r page_155, box) 

The Martin reference also provides some examples. These models are not viewed as static. 
The Martin reference teaches modeling the enterprise. The principles and techniques are dynamic. 

b. Flow Control - The Applicant does not explicitly claim flow control. However, when the 
Applicant states in the claims "method logic is continuous" this is interpreted as meaning the 
method (a common feature in object technology) can run until a outside interrupt occurs. This is a 
product of flow control resulting from the logic structure of a computer program. There are many 
claims to what the Examiner interprets as claims to flow control. Flow control is the tracing the 
path of an executing of a program. The exact path the execution of a program will follow is 
determined by the values of the attributes and the control conditions encountered. The examples 
of the programming constructs such as Martin page 148 show the difference paths flow control 
can take depending on execution of operations such as CHECK IN COPY , FILL REQUEST and 
BOOK OVERDUE. The values of attributes are tested to determine the path taken. Many claims 
have made claim to flow control which is inherent to the execution of a computer programs. 

c. Claim 3 contains the following limitation "... the step of defining a first control point further 
comprises: 
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(al) decorating the object to dynamically insert a first control point such that the object acquires 
this new control point." 

The Examiner interprets the "decorating" to mean the entry of programming information such as 
the operations/methods and the entry of control points in a programming environment. 
- ClainuRejeciians^$5MSC-§-W2 

10. The following is a quotation of the appropriate paragraphs of 35 U.S.C.§ 102 that form 
the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless — 

(a) the invention was known or used by others in this country, or patented or described in a printed publication in 
this or a foreign country, before the invention thereof by the applicant for a patent. 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or 
on sale in this country, more than one year prior to the date of application for patent in the United States. 

11. Claims 1 - 98 are rejected under 35 U.S.C. 102(a) as being anticipated by "Principles of 
Object-Oriented Analysis and Design", James Martin, published June 1, 1992. 

The Martin teaches the underlying theory of building an Object Oriented Computer Aided 
Software Engineering (OO-CASE) tools in his 1992 text book. The Martin should be taken as a 
whole, however, focus of the rejection is on the Chapters 9 and 10. The Martin references covers 
the very basics of object technology that one of ordinary skill should have known well before the 
time of invention: 

Chapter 2 - Basic Concepts 

Chapter 3 - Why Object-Oriented ? 

Chapter 4 - Basic Guidelines 
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Chapter 6 - Categorizing Objects 

Chapter 7 - Relationships Among Object Types 

Chapter 8 - State and State Changes 

Chapter 9 - Events, Triggers, and Operations 
Chapter. lCLJRules 

Chapter 1 1 - How Diagrams Interrelate 

Chapter 12 - Basic Concepts of 00 Design 

Chapter 15 - Method Creation 

Chapter 18 - OO-CASE Tools 

Appendix A - Recommended Diagraming Standards 
The Martin book in addition to containing foundation knowledge of object oriented technology it 
teaches applying a set of rules comprising the placing of logic (program statements) in a pre- 
method control before the logic of a method and post method control point after the logic of a 
method. Martin also teaches associating a set of rules with each control point based on the class 
of the object in which the method resides, name of the method and type of control point and 
invoking methods. 
Claim 1 

Martin anticipates a computer implemented process for applying a set of rules (Martin, Chapter 
10, RULES, and page 138-139 and 249-251), the process comprising: 
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(a) placing a pre-method control before logic of a method (Martin, page 142, operation 
precondition) and post-method control point after the logic of the method (Martin, page 142, 
postcondition ) 

(b) associating a set rules with each control point (Martin, page 142, 147 "Operation" as per (a) 

above)-based-on-a~Glass-ofobject4n-which4^ 

associated with diagrams of 00 ..."), name of the method, and type of control point, whether 
the pre-method control point or the post-method control point (Martin, page 142, operation 
precondition) ; 

(c) invoking the method ( Martin, page 1 16), wherein encountering each control point during the 
execution of the method comprises (Martin, page 142, postcondition ): 

(i) determining if the encountered control point is active (Martin, page 122, IF structure in center 
diagram ) ; 

(ii) on the basis of an active control point (Interpreted as the result of the IF structure above 
further described in Appendix A on page 381 Control Conditions): 

1) selecting rules based on a set of rules associated with the active control point associated in step 
(Martin, page 122, first diagram example is the control condition to fire missile ) (b); 

2) running the selected rules (Martin, page 122, rule that lead to the control condition ); 

3) obtaining results from running the rules (Martin, page 122, trigger rule at the bottom of the 
page ); and 
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4) combining the results using a combining algorithm specified by the control point (Martin, page 
122, A control condition can function as a combining algorithm as seen in diagram in middle of 
the page and page 126 Figure 9.9 and Martin teaches a way to have a combing algorithm where 
one of three operations are selected as on page 124, and Martin teaches a way to have a 
combining-algorithm-where-one-can be. selected-as-taught-ia-the-mutually,exclusi-v e notation on t he 
bottom of page 125). 
Claim 2 

Martin anticipates a computer implemented process for applying a set of rules (Martin, Page 
166, Rules Linked to Diagrams a product and Martin, page 172 from operations to methods) 
comprising: 

(a) defining an object (Martin, page 171, CLASS - bottom of page); 

(b) defining at least one method in the object (Martin, page 173, Method - top of page and page 
116 and page 167 Rule editor ); 

(c) defining a control point just before logic of at least one method (Martin, page 173, diagram in 
center of page); and 

(d) associating a set of rules with the control point (Martin, page 173, diagram in center of 
page). 

Claim 3 

In the process of claim 2, the step of defining a first control point further comprises: 
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(al) decorating the object to dynamically insert a first control point such that the object acquires 
this new control point (Martin, teaches how the object model and rules are associated in Chapter 
5 page 59, on page 60 of Martin last paragraph OO-CASE tools states last paragraph "Every time 
we tell an advanced CASE tool about classes, inheritance, and so on, it should generate code." 

Jhe-nextsentence.menlionsxodexa The reference also mentions the 

diagrams are executable such as on page 142 - The reference teaches Object Oriented Computer 
Aided Software Engineering (OO-CASE) tools and their features. OO-CASE tools as described 
create objects and methods much of which is described in claim 2 ). 
Claim 4 

In the process of claim 2, the step of defining at least one control point further comprises: 
(cl) adding the at least one control point through the technique of generating required code in the 
compiler or with a preprocessor. As per claim 3 the diagrams generate code also see the definition 
of Instant CASE or I-CASE Martin, pages 7, 243, 282-283, 284, 293, 294, 351 and 352. 
Claim 5 

In the process of claim 2, the step of defining at least one control point further comprises: 
(cl) manually inserting the at least one control point and encoding the control point in the 
implementation of a hosting object. As per claim 3. 
Claim 6 

In the process of claim 2, the step of defining at least one control point further comprises: 
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(cl) externalizing the at least one control point as a class and instantiating it at the at least one 
control point (Martin, page 133 - 136, BOX and claim 1 and page 167 OMW screen shot) 
Claim 7 

The process of claim 2 further comprises: 

(e) defining a second control point just after the log ic of each method; and 

(f) associating a second set of rules with the second control point ( Martin, in many locations 
teaches the ability to have more than 1 control point and additional rules see page 164 for an 
example). 

Claim 8 

In the process of claim 7, wherein the rules in the second set of rules are associated to the second 
control point without considering the rules in the first set of rules associated with the at least one 
control point as per claim 7. 
Claim 9 

In the process of claim 7, wherein a set of rules is defined as having N number of rules, N being at 
least zero. As per claim 1 the presents of a single RULE means it exists and the count of rules 
present is greater than zero. 
Claim 10 

In the process of claim 2, the step of associating at least one control point further comprises: 
(cl) defining, with a control point, at least one of a rule selecting algorithm and a rule-results 
combination algorithm As per claim 1 . 
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Claim 11 

The process of claim 2, further comprises: 

(e) changing rules associated with the control point contained in the set of rules. As per claims 3 
and claim 4 OO-CASE and I-CASE by definition. 

_ClaimJ2 

Martin anticipates a computer implemented process for applying a set of rules ( as per claim 2), 
comprising: 

(a) invoking a method in an object ( as per claim 2); 

(b) encountering an active control point during the invocation of the method ( as per claim 2); 

(c) selecting rules associated with the method of the object at the control point ( as per claim 2); 

(d) invoking the rules ( as per claim 2); and 

(e) combining results from invoking the rules as per claim 1 . 
Claim 13 

The process of claim 12, wherein the rules perform a variety of actions (Martin, page 164, a 

variety of actions can occur such as Invoice Student OR Get Dorm depending on the outcome of 

the Remote Student registered condition ) conditioned by the fact that rules may be associated 

with particular, regularly occurring points in the object model Martin, 

(Martin, page 166, RULES LINKED TO DIAGRAMS, "The importance of rules was 

emphasized in Chapter 10 which indicated that rules can be connected to any of the 00 

diagrams".) 



Application/Control Number: 09/204,973 
Art Unit: 2122 



Page 12 



Claim 14 

The process of claim 12, wherein the rules perform at least one function which varies over time 
(Martin, page 117, clock events and page 144 Rules Associated with Event Diagrams - " If time 
is between 9 AM to 5 PM", Martin, page 394, Clock Events). 

Claim45 

A process of claim 12, wherein a control point occurs just before logic of the method begins, just 
after the logic of the method completes, or at both just before logic of the method begins and just 
after the logic of the method completes as per claim 1 . 
Claim 16 

Martin anticipates a computer implemented process for applying a set of rules ( as per claim 2) 
comprising: 

(a) defining an object ( as per claim 2); 

(b) defining at least one method in the object ( as per claim 2); 

(c) defining at least one control point in the at least one method ( as per claim 2). 

(d) defining rules to the at least one control point on basis the object's class name, method, name, 
and position of the at least one control point in the method (Martin, Chapter 12, BASIC 
CONCEPTS OF OO DESIGN, page 172 - 173, the relationship between classes and objects and 
the relationship between rules and object modeling ). 

Claim 17 
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In the process of claim 16, further comprising the step of activating at least one control point 
having associated rules as per claim 1 . 
Claim 18 

The process of claim 16 further comprises: 

(e) encountering a first control point (Martin, page 173, control point with a Time Event) ; 

(f) running the rules associated with the first control point (Martin, page 173, control point with 
a Time Event); and 

(g) affecting behavior of the object based on running the rules associated with the first control 
point (The flow control is controlled by the Rule associated with the Control point as per Martin, 
page 381). 

Claim 19 

In the process of claim 18, the step of affecting the behavior of the object further comprises: 

(h) associating different rules to a control point ( as per claim 14 - Different rules based on the 
time of day affects the flow control/ behavior). 

Claim 20 

In the process of claim 18, the step of affecting the behavior of the object further comprises: 
(h) defining another control point (Examiner Interpretation of "defining another control point" the 
meaning could be at design time or runtime. Design time would involve the interaction with the 
OO-CASE tool as on Martin, page 162, Run time would mean the behavior changes value such 
as attribute which influence the path the control flow takes. This is the point of programming. The 
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ability to model a problem domain and execute code that process information that reflects the 
modeled problem - Flow Control as determined by the running of the program such as Martin, 
page 163). 
Claim 21 

Jnthe^rocessxrfxlaimAS^ 

(h) associating rules to a second control point ( Martin, page 163, Multiple control points 

defined). 

Claim 22 

In the process of claim 16, further comprising a step of deactivating the at least one control 
point.( As per claim 1. The control point is determined if it is active or not. If one takes the 
Martin, page 163 example where the timed event is part of the Waitlisted functionality the Timed 
event occurs at a specific time the Timed Event is one example of activating and deactivating the 
control point also see Martin, Appendix A, page 394) 
Claim 23 

Martin anticipates a computer implemented process for applying a set off rules ( as per claim 2), 
comprising 

(a) defining an object ( as per claim 2); 

(b) defining a method in the object ( as per claim 2); 

(c) defining a first control point of the method ( as per claim 2); 

(d) determining rules associated with the first control point ( as per claim 2); 
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(e) defining a second control point of the method ( as per claim 2); and 

(f) determining rules associated with the second control point ( as per claim 2). 
Claim 24 

A computer implemented process as in claim 23 further comprising: 

(g) separately selecting, running and combining th e results of rules determined to be associated 
with either control point as per claim 1 . 

Claim 25 

In the process of claim 23 wherein the first control point is a pre-method trigger point ( Martin, 
page 142, diagram top of page, page 381 Trigger Rules). 
Claim 26 

In the process of claim 23 wherein the second control point is a post-method trigger point 
(Martin, page 115, Postconditions in cause and effect isolation, page 141, Post Condition page 
381, Trigger Rule). 
Claim 27 

Martin anticipates a computer implemented process for defining an object (Martin, page 166 - 
167, Link between, Diagrams, Rules and Objects ) comprising: 

defining an object; (Martin, page 144, Box 10.3, and page 169 - 176 and as per claim 2) 
defining a method in the object by: defining method logic ( as per claim 2) ; 
placing the method logic in the method (Martin, page 173, methods is the Specification of an 
operation and as per claim 2); 
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defining at least one control point ( as per claim 2); 

and placing the at least one control point in the method wherein the method logic is continuous. 
(Martin, page 224, DO and FOR loops, page 225, Loops in action diagrams). 
Claim 28 

Axomputer-implemented-process-for-defining.an.objecLas in claim_2_7, wh erein the step of placing, 
the at least one control point further comprises placing the at least one control in the method 
before the method logic ( as per claim 1). 
Claim 29 

A computer implemented process for defining an object as in claim 27, wherein the step of placing 
the at least one control point further comprises placing the at least one control in the method after 
the method logic ( as per claim 1). 
Claim 30 

A computer implemented process for defining an object as in claim 27, wherein the at least one 
control point comprises two control points and further comprises: placing a first control point in 
the method before the method logic; and placing a second control point in the method after the 
method logic ( Martin, page 126, Figure 9.9). 
Claim 31 

A computer implemented process for defining an object as in claim 27, further comprises: flagging 
the at least one control point on the basis of being active ( as per claim 1). 
Claim 32 
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A computer implemented process for defining an object as in claim 27, wherein the step of 
defining the at least one control point further comprising: defining a rule selection algorithm 
associated with the at least one control point (Martin, page 168, control point rule illustrated). 
Claim 33 

-A~computer4mplemented-process-for-defining-an-objectasinxlaim 2 7 , wherein.the_step_of 

defining the at least one control point further comprising: defining a rule result combination 
algorithm associated with the at least one control point. As per claim 1. 
Claim 34 

A computer implemented process for defining an object as in claim 27, wherein the step of 
defining the at least one control point further comprises: defining a rule selection algorithm for the 
at least one control point; and defining a rule result combination algorithm for the at least one 
control point As per claim 1 . 
Claim 35 

A computer implemented process for defining an object as in claim 27, further comprising: 
associating at least one rule with the at least one control point. As per claim 32. 
Claim 36 

Martin anticipates a computer implemented process for defining a rule comprising: creating the 
rule (Martin, page 167, Rule Editor) ; associating the rule with an object class ( Martin, page 
167, Figure 11.14); associating the rule with a method within the object class ( Martin, page 173, 
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operations are methods); and associating the rule with an occurrence of a control point within the 
method ( Martin, page 168, Figure 11.16). 
Claim 37 

A computer implemented process for defining a rule as in claim 36 wherein the occurrence of the 

xontoLpointJwith^ logic . As per cla i m 1. 

Claim 38 

A computer implemented process for defining a rule as in claim 36 wherein the occurrence of 
control point within the method being after method logic. As per claim 1 . 
Claim 39 

A computer implemented process for defining a rule as in claim 36, further comprising: 
associating the rule with another object class ( Martin, page 267, the ability to access a 
method/Rule from more than one object and the concept of Reuse which is a key factor in object 
oriented technology Martin, page 248, Box 16.2 Maximize reusability) ( This claim could also be 
interpreted as claiming the principle of inheritance as described on Martin, page 266 - 268). 
Claim 40 

A computer implemented process for defining a rule as in claim 36, further comprising: 
associating the rule with another method within the object class. As per claim 39. 
Claim 41 
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A computer implemented process for defining a rule as in claim 36, further comprising: 
associating the rule with another control point within the method of the object class (Martin, 
page 166 - 168, the rule associated to the control point , page 233, RULES) 
Claim 42 

Martin-anticipates-a-com — 
comprising: selecting an object class; selecting a method within the object class; invoking the 
method; processing rules associated with the method comprising: encountering a control point 
associated with the method; determining if the control point is active; and finding at least one rule 
associated with an active control point. (Interpreted as the running of the code generated by claim 
2). 

Claim 43 

A computer implemented process for applying a set of rules as in claim 42, wherein the step of 
finding at least one rule further comprises: accessing a selecting algorithm associated with the 
active control point ( as per claim 1); and selecting at least one rule using the selecting algorithm ( 
as per claim 10 and The IF structure in the control point as per Martin, page 168 ). 
Claim 44 

A computer implemented process for applying a set of rules as in claim 42, where in the step of 
processing rules further comprises: running the at least one rule; determining results from running 
the at least one rule; accessing a combining algorithm associated with the control point; and 
combining the results using the combining algorithm. As per claim 1 . 
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Claim 45 

Martin anticipates a computer implemented process for applying a set of rules, comprising: 
selecting an object class; selecting a method within the object class; invoking the method; 
processing rules comprising: encountering a control point; accessing a selecting algorithm 
.assQciatedJwith4hexontrol^ t he selec ting_alg orithm . A s 

per claim 42. 
Claim 46 

Martin anticipates a computer implemented process for applying a set of rules, comprising: 
selecting an object class; selecting a method within the object class; invoking the method; 
processing rules comprising: encountering a control point; finding at least one rule associated with 
the control point; running the at least one rule; determining results on the basis of running the at 
least one rule; accessing a combining algorithm associated with the control point; and combining 
the results using the combining algorithm. .As per claim 1 - the running of the executable 
generated from the model. 
Claim 47 

Martin anticipates a computer implemented process for applying a set of rules, comprising: 
selecting an object class; selecting a method within the object class; invoking the method; 
processing rules comprising: encountering a first control point associated with the method; 
determining if the first control point is active (the running of code from claims 1 and 2 and 
implementations such as page 164 Fig 1 1.10); executing method logic of the method; 
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encountering a second control point associated with the method; determining if the second control 
point is active; finding a set of rules associated with one of the first control point and the second 
control point, wherein the set of rules contains not less than zero rules as per claim 9. 
Claim 48 

Martin-antteipates-a-computeumpte^ set of rules, comprising: 

selecting an object class; selecting a method within the object class; invoking the method; 
processing rules comprising: encountering a control point associated with the method; finding at 
least one rule associated with the control point prior to executing method logic of the method; 
running the at least one rule; obtaining results on the basis of running the at least one rule; and 
controlling the method on the basis of the results ( The running of code from claims 1 and 2). 
Claim 49 

A computer implemented process for applying a set of rules as in claim 48, wherein the step of 
controlling the method comprises: exiting the method. Martin, page 236, use of "return" in C++ 
and it is well known in C++ that reaching the end of a method such as flow control reaching the 
last "}" in the method declassify will return flow control to the method that called this method or 
terminate. In either path the method has performed an exit. 
Claim 50 

A computer implemented process for applying a set of rules as in claim 48, wherein the step of 
controlling the method comprises: executing method logic of the method. The running of the 
executable code produced by the modeling from claim 1 - Flow control. 
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Claim 51 

Martin anticipates a data processing system for defining an object comprising: defining means for 
defining an object; defining means for defining a method in the object by: defining means for 
defining method logic; placing means for placing the method logic in the method; defining means 
■foiidefining-at-least-one-ControLpoint;-and-pla ci ng m ean s f or placing th e atle ast o n e contro l point 
in the method wherein the method logic is continuous. As per claim 27. 
Claim 52 

A data processing system for defining an object as in claim 51, wherein the step of placing the at 
least one control point further comprises placing means for placing the at least one control in the 
method before the method logic. As per claim 1 . 
Claim 53 

A data processing system for defining an object as in claim 51, wherein the step of placing the at 
least one control point further comprises placing means for placing the at least one control in the 
method after the method logic. As per claim 1 . 
Claim 54 

A data processing system for defining an object as in claim 51, wherein the at least one control 
point comprises two control points and further comprises: placing means for placing a first control 
point in the method before the method logic; and placing means for placing a second control point 
in the method after the method logic. As per claims 2 and 7. 
Claim 55 
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A data processing system for defining an object as in claim 51, further comprises: flagging means 
for flagging the at least one control point on the basis of being active. As per claim 31. 
Claim 56 

A data processing system for defining an object as in claim 51, wherein the step of defining the at 

Jeast^one-controLpQintfurther-comprising:„defining.means fo£.defining-ajiile-S.ele£tion algorithm 
associated with the at least one control point. As per claim 32. 
Claim 57 

A data processing system for defining an object as in claim 51, wherein the step of defining the at 
least one control point further comprising: defining means for defining a rule result combination 
algorithm associated with the at least one control point as per claim 10. 
Claim 58 

A data processing system for defining an object as in claim 51, wherein the step of defining the at 
least one control point ( as per claims 1 and 2) further comprises: defining means for defining a 
rule selection algorithm for the at least one control point; and defining a rule result combination 
algorithm for the at least one control point. As per claim 34. 
Claim 59 

A data processing system for defining an object as in claim 51, further comprising: associating 
means for associating at least one rule with the at least one control point. As per claim 8. 
Claim 60 
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Martin anticipates a data processing system for defining a rule comprising: creating means for 
creating the rule; associating means for associating the rule with an object class; associating means 
for associating the rule with a method within the object class; and associating means for 
associating the rule with an occurrence of a control point within the method. As per cliam 36. 

Claim 61 

A data processing system for defining a rule as in claim 60 wherein the occurrence of the control 
point within the method being before method logic. As per claim 1. 
Claim 62 

A data processing system for defining a rule as in claim 60 wherein the occurrence of control 
point within the method being after method logic. As per claim 1 . 
Claim 63 

A data processing system for defining a rule as in claim 60, further comprising: associating means 
for associating the rule with another object class. ( Martin, page 267, the ability to access a 
method/Rule from more than one object and the concept of Reuse which is a key factor in object 
oriented technology Martin, page 248, Box 16.2 Maximize reusability) ( This claim could also be 
interpreted as claiming the principle of inheritance as described on Martin, page 266 - 268). 
Claim 64 

A data processing system for defining a rule as in claim 60, further comprising: associating means 
for associating the rule with another method within the object class. As per claim 39. 
Claim 65 
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A data processing system for defining a rule as in claim 60, further comprising: associating means 
for associating the rule with another control point within the method of the object class. As per 
claim 1. 
Claim 66 

Martin anticipates a data processing system for app lying a set of rules, comprising: selecting 
means for selecting an object class; selecting means for selecting a method within the object class; 
invoking means for invoking the method; processing means for processing rules associated with 
the method comprising: encountering means for encountering a control point associated with the 
method; determining means for determining if the control point is active; and finding means for 
finding at least one rule associated with an active control point. As per claim 42. 
Claim 67 

A data processing system for applying a set of rules as in claim 66, wherein the step of finding at 
least one rule further comprises: accessing means for accessing a selecting algorithm associated 
with the active control point; and selecting means for selecting at least one rule using the selecting 
algorithm. As per claim 43. 
Claim 68 

A data processing system for applying a set of rules as in claim 66, where in the step of processing 
rules further comprises: running means for running the at least one rule; determining means for 
determining results from running the at least one rule; accessing means for accessing a combining 
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algorithm associated with the control point; and combining means for combining the results using 
the combining algorithm. As per claim 44. 
Claim 69 

Martin anticipates a data processing system for applying a set of rules, comprising: selecting 
-meansibr-sdecting-an-ob^^ a method within the object class; 

invoking. means for invoking the method; processing means for processing rules comprising: 
encountering means for encountering a control point; accessing means for accessing a selecting 
algorithm associated with the control point; and selecting means for selecting at least one rule 
using the selecting algorithm. As per claim 45. 
Claim 70 

Martin anticipates a data processing. system for applying a set of rules, comprising: selecting 
means for selecting an object class; selecting means for selecting a method within the object class; 
invoking means for invoking the method; processing means for processing rules comprising: 
encountering means for encountering a control point; finding means for finding at least one rule 
associated with the control point; running means for running the at least one rule; determining 
means for determining results on the basis of running the at least one rule; accessing means for 
accessing a combining algorithm associated with the control point; and combining means for 
combining the results using the combining algorithm. As per claim 46. 
Claim 71 
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Martin anticipates a data processing system for applying a set of rules, comprising: selecting 
means for selecting an object class; selecting means for selecting a method within the object class; 
invoking means for invoking the method; processing means for processing rules comprising: 
encountering means for encountering a first control point associated with the method; determining 

-means-for-detenniningif-the^ per claim 2 )^ executing means for 

executing method logic of the method (as per claim 2); encountering means for encountering a 
second control point associated with the method; determining means for determining if the second 
control point is active; finding, means for finding a set of rules associated with one of the first 
control point and the second control point (as per claim 7), wherein the set of rules contains not 
less than zero rules. As per claim 9. 
Claim 72 

Martin anticipates a data processing system for applying a set of rules, comprising: 
selecting means for selecting an object class; selecting means for selecting a method within the 
object class; invoking means for invoking the method; processing means for processing rules 
comprising: encountering means for encountering a control point associated with the method; 
finding means for finding at least one rule associated with the control point prior to executing 
method logic of the method; running means for running the at least one rule; obtaining means for 
obtaining results on the basis of running the at least one rule; and controlling means for 
controlling the method on the basis of the results. As per claim 48. 
Claim 73 
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A data processing system for applying a set of rules as in claim 72, wherein the step of controlling t 
the method comprises: exiting means for exiting the method. As per claim 49. 
Claim 74 

A data processing system for applying a set of rules as in claim 72, wherein the step of controlling 

the method comprises' executing means for executing method logicof the method. As per claim 

50. 

Claim 75 

Martin anticipates a computer program product embodied on a computer readable medium 
containing instructions for a computer implemented process for defining an object, the instruction 
comprising: instructions for defining an object; instructions for defining a method in the object by: 
instructions for defining method logic; instructions for placing the method logic in the method; 
instructions for defining at least one control point; and instructions for placing the at least one 
control point in the method wherein the method logic is continuous. As per claim 51 . 
Claim 76 

A computer program product for defining an object as in claim 75, wherein the instruction of 
placing the at least one control point further comprises placing the at least one control point in the 
method before the method logic. As per claim 1. 
Claim 77 
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A computer program product for defining an object as in claim 75, wherein the instruction of 
placing the at least one control point further comprises placing the at least one control point in the 
method after the method logic. As per claim 1. 
Claim 78 

-A-computerLprogram.producLfoii-defining an ohjecLas in cla im 75, wherein the at least one 

control point further comprises two control points and further comprises: instructions for placing 
a first control point in the method before the method logic; and instructions for placing a second 
control point in the method after the method logic. As per claim 1. 
Claim 79 

A computer program product for defining an object as in claim 75, further comprises: instructions 
for flagging the at least one control point on the basis of being active. As per claim 31. 
Claim 80 

A computer program product for defining an object as in claim 75, wherein the instruction of 
defining the at least one control point further comprising: instructions for defining a rule selection 
algorithm associated with the at least one control point. As per claim 32. 
Claim 81 

A computer product for defining an object as in claim 75, wherein the instruction of defining the 
at least one control point further comprises: instructions for defining a rule combination algorithm 
associated with the at least one control point. As per claim 33. 
Claim 82 
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A computer program product for defining an object as in claim 75, wherein the step of defining 
the at least one control point further comprises: instructions for defining a rule selection algorithm 
for the at least one control point; and instructions for defining a rule result combination algorithm 
for the at least one control point. As per claim 34. 

jCIaim-83 

A computer program product for defining an object as in claim 75, further comprising: 
instructions for associating at least one rule with the at least one control point. As per claim 35. 
Claim 84 

Martin anticipates a computer program product embodied on a computer" readable medium 
containing instructions for a computer implemented process for defining a rule, the instruction 
comprising: instructions for creating the rule; instructions for associating the rule with an object 
class; instructions for associating the rule with a method within the object class; and instructions 
for associating the rule with an occurrence of a control point within the method. As per claim 36. 
Claim 85 

A computer program product for defining a rule as in claim 84 wherein the occurrence of the 
control point within the method being before method logic. As per claim 1 . 
Claim 86 

A computer program product for defining a rule as in claim 84 wherein the occurrence of control 
point within the method being after method logic. As per claim 1. 
Claim 87 
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A computer program product for defining a rule as in claim 84, further comprising: instructions 
for associating the rule with another object class. As per claim 39 or 63. 
Claim 88 

A computer program product for defining a rule as in claim 84, further comprising: instructions 

for assorting the rule with another method wit hin the object class. As per claim 39 or 64. 

Claim 89 

A computer implemented process for defining a rule as in claim 84, further comprising: 
instructions for associating the rule with another control point within the method of the object 
class. As per claim 65. 
Claim 90 

Martin anticipates a computer program product embodied on a computer readable medium 
containing instructions for a computer implemented process for applying a set of rules, the 
instruction comprising: instructions for selecting an object class; instructions for selecting a 
method within the object class; instructions for invoking the method; instructions for processing 
rules associated with the method comprising: instructions for encountering a control point 
associated with the method; instructions for determining if the control point is active; and 
instructions for finding at least one rule associated with an active control point. As per claim 1. 
Claim 91 

A computer program product for applying a set of rules as in claim 90, wherein the step of finding 
at least one rule further comprises: instructions for accessing a selecting algorithm associated with 
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the active control point; and instructions for selecting at least one rule using the selecting 
algorithm. As per claim 43. 
Claim 92 

A computer program product for applying a set of rules as in claim 90, where in the step of 

processing rules farther comprises- instructions for running the at least one rule; inst ructions for 
determining results from running the at least one rule; instructions for accessing a combining 
algorithm associated with the control point; and instructions for combining the results using the 
combining algorithm. As per claim 1 . 
Claim 93 

Martin anticipates a computer program product embodied on a computer readable medium 
containing instructions for a computer implemented process for applying a set of rules, the 
instruction comprising: instructions for selecting an object class; instructions for selecting a 
method within the object class; instructions for invoking the method; instructions for processing 
rules comprising: instructions for encountering a control point; instructions for accessing a 
selecting algorithm associated with the control point; and instructions for selecting at least one 
rule using the selecting algorithm. As per claim 42. 
Claim 94 

Martin anticipates a computer program product embodied on a computer readable medium 
containing instructions for a computer implemented process for applying a set of rules, the 
instruction comprising: instructions for selecting an object class; instructions for selecting a 
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method within the object class; instructions for invoking the method; instructions for processing 
rules comprising: instructions for encountering a control point; instructions for finding at least one 
rule associated with the control point; instructions for running the at least one rule; instructions 
for determining results on the basis of running the at least one rule; instructions for accessing a 
combining algorithm associated with the control point; and inst ructions for combining the results 
using the combining algorithm. As per claim 1 or 46. 
Claim 95 

Martin anticipates a computer program product embodied on a computer readable medium 
containing instructions for a computer implemented process for applying a set of rules, the 
instruction comprising: instructions for selecting an object class ( as per claim 42); instructions for 
selecting a method within the object class; instructions for invoking the method; instructions for 
processing rules comprising: instructions for encountering a first control point associated with the 
method; instructions for determining if the first control point is active; instructions for executing 
method logic of the method; instructions for encountering a second control point associated with 
the method; instructions for determining if the second control point is active (Asper claim 47); 
instructions for finding a set of rules associated with one of the first control point and the second 
control point, wherein the set of rules contains not less than zero rules. As per claim 9. 
Claim 96 

Martin anticipates a computer program product embodied on a computer readable medium 
containing instructions for a computer implemented process for applying a set of rules, the 
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instruction comprising: instructions for selecting an object class; instructions for selecting a 
method within the object class; instructions for invoking the method; processing rules comprising: 
instructions for encountering a control point associated with the method; instructions for finding 
at least one rule associated with the control point prior to executing method logic of the method; 

instmcUons-for-iimnm^ rule; instructions for obtainingj^sults on the basis of 

running the at least one rule; and instructions for controlling the method on the basis of the 
results. As per claim 48. 
Claim 97 

A computer program product for applying a set of rules as in claim 96, wherein the step of 
controlling the method comprises: instructions for exiting the method. Martin, page 236, use of 
"return" in C++ and it is well known in C++ that reaching the end of a method such as flow 
control reaching the last "}" in the method declassify will return flow control to the method that 
called this method or terminate. In either path the method has performed an exit. 
Claim 98 

A computer program product for applying a set of rules as in claim 96, wherein the step of, 
controlling the method comprises: instructions for executing method logic of the method. As per 
claims 50. 

Summary 

12. The rejection under Martin is a fundamental teaching from June 1992 which contains 
features inherent to Object Oriented technology and a primer book on the technology. The WFT 
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rejection is a commercial product for use and for sale since April 1997 which implementations 
Rules in an Object Oriented CASE tool. Both rejections support the concept that the tools are 
designed for the end user to implement rules without formal programming experience. Rational 
Rose is also a OO-CASE tool which teaches the ability implement rules at a Programmer level. 
_ _ Conclusion „ 

13. The undisclosed prior art of Assignee (IBM) is made of record and not relied upon is 
considered pertinent to applicant's disclosure. 

A. "Business/Enterprise Modeling", Robert Katz, IBM Systems Journal, Armonk 1990, Vol 29, 
Issue 4, page 509, 17 pages 

B. "The Impact of Object-Orientation on Software Development", A.A.R. Cockburn, IBM 
Systems Journal, 1993, Vol 32, No 3, pages 420-444. 

C. "Process Automation in Software Application Development", K.D. Saracelli et al, IBM 
Systems Journal, 1993, Vol 32, No 3, pages 376-396. 

14. Prior art made of record and not relied upon is considered pertinent to applicant's 

disclosure. 

D. Template Software Inc., product line contains the SNAP programming language and the 
Workflow Template. The a subset of the documentation sets for the products contains the 
following manuals that cover their Workflow system with RULES. 

Workflow released April 3, 1997 

Developing a WFT Workflow System 
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Using the WFT Development Environment 
E. Rational Corporation's product Rational Rose C++ version 4, released in 1996. 
Rational Rose C++ version 4.0 contains a document set containing the following documents: 

• Round-Trip Engineering with Rational Rose/C++ 

• Using-RationaLRoseJLO 

• UML, Booch & OMT Quick Reference for Rational Rose 4.0 

This product set should be viewed as the state of the technology in the mid 1990's. The Rational 
Rose product was eliminated from consideration because the Applicant appears to be using the 
term "Externalizing Rules" to mean the domain expert is the end user not the programming. 
Rational Rose the rules are implemented by the programmer not the domain expert. Both Martin 
and Template implement rules which are intended to be entered by the domain expert. 

Correspondence Information 
15. Any inquiry concerning this communication or earlier communications from the Examiner 
should be directed to Todd Ingberg whose telephone number is (703) 305-9775. The Examiner 
can normally be reached on Monday, Tuesday, Thursday and Friday from 6:30 a.m. to 5:00 p.m. 
Until, October 22, 2001 then the Examiner's work schedule will be Monday through Thursday 
from 6:30 a.m. to 5:00 p.m. 



If attempts to reach the examiner by telephone are unsuccessful, the Examiner's 
Supervisor, Mark Powell is on an extended work detail, Acting Supervisor Kevin Teska can be 
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reached at (703)305-9704. Any response to this office action should be mailed to: Director of 
Patents and Trademarks Washington, D.C. 20231 or faxed to: (703) 308-9051, (for formal 
communications intended for entry) Or: (703) 308-1396, (for informal or draft communications, 
please label "PROPOSED" or "DRAFT") Hand-delivered responses should be brought to 
Grysta^ark-n,-2121-<^staI-Drive^ 
floor). 



Todd Ingberg 



September 30, 2001 
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EVENTS, TRIGGERS, AND OPERATIONS 



t||jEyENTS 



To model the behavior of object-oriented systems, we 
, .... determine what events happen. Events cause the sys- 

| /terns to take various actions. We map the events and corresponding actions with 
m& event diagram. The following are examples of events. 



Vk'-r,. - 



The cat has 
"had kittens 



An order is 
* received 



► Invoice is 
transmitted 

CASE user 
^ created an 
object on the 
screen 



Aunt Agatha 
W has arrived 
^ for tea 

An airline 
» booking is 
requested 

► Factory 
schedule is 
recomputed 

Nuclear forces 
^ went to 
w DEFCON2 

alert status 



Traffic light 
"turns to green 



Job is 
* completed 



VCR tape 
► rewind 
finishes. 



► Alarm clock 
goes off 



*.. The event diagram shows events and the operations triggered by ev -ems. End 
users tend To Snk intuitively about events and operations triggered by everts. 
t^^Aevshoddbe taughthow to read event diagrams and validate their cor- 
feSs^^f^gram^s a primary means of communicatmg 00 behavior 



Jtb end users. 



A SEQUENCE 
QOF OPERATIONS 



An event diagram contains a sequence of operations. 
The operations are drawn with round-cornered boxes 
as in the following examples: 
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Launch 
Missile 



Rewind 
VCR Tape 



Update 
Employee 
Record 



Transmit 
Invoice 



Create 
Waitlist 



Cancel 
Account 



Compress 
Image 



Fill 
Order 



Accept 
Order 





\ 




Start 




Engine 




J 



Figure 9.1 tells a story: a driver runs a red light and is chased by the police. 
"In such a diagramrthe sequence of operations is self^explanatorjrand can be easr=- 
ly understood by end users. We need only add some detail to show events, trigger 
rules, and control conditions. 

The term operation refers to a unit of processing that can be requested. 
The corresponding procedure is implemented with a method. The method is 
the specification of how the operation is carried out: it is the script for the 
operation. At the program level, the method is the code that implements the 
operation. 

Operations are invoked An invoked operation is an instance of an opera- 
tion. An operation may or may not change the state of an object. If it does, an 
event occurs. 



EVENTS AND While some events are external to the system, most 

OPERATIONS occur within the system and result from an operation. 

Events are drawn as small solid triangles. When an 
event results from an operation, the triangle is attached to the operation box, as 
shown on the next page. 
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Driver sets 
car in 
motion 



Car placed 
in motion 



Police placed 



Police watch ] on alert 
for traffic 
offenders 



Traffic light 
changes 
color 



Driver reacts 
to red light 




Traffic light 
changed to red 



Police l-H Police dont see infraction 



decide 
action 



I Police decide to ignore it 



Police 
activate siren 
& tights 



Police 
siren 
activated 



Driver ran 
red light 



Police decide 
to give ticket 



EVEtv 
STAT 



An » 
diag 



Figure 9 A An event diagram for a car chase with all symbols and event sub- 
type representation contracted. 
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Operation 



Event Type 



> 



The event occurs at a point in time. The small triangle represents this point 
in time when the corresponding state change occurs. 



Customer 
pays 
Invoice 



y 



Invoice 
paid 



Produce 
Check 



> 



Check 
produced 



Sometimes, one operation results in multiple events: 



Store 
Part in Bin 



• Bin Contents increased 
Part stored in Bin 

Inventory Storage Process completed 



EVENTS AND 
STATE CHANGES 



Events are, in effect, changes in the state of an 
object. Traffic Light turns to Green is a change in 
. . the state of the object Traffic Light. Job is complet- 

ed is a change in the state of Job. An Order is received results in the creation 

Invoice* ° bjeCt " ,nV0 ' Ce ' S transmitted is a cl ? an 8 e in the state of 
When the stock level of an item falls below its reorder,: point, this is a 
change in the state of a Stock object. Such an event also prompts us to act 

u . 1J . The P rocess causin S a state chan g e m ay not be a part of the system we are 
building However, the underlying object and its event may be important to the 
systems being specified. 
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An event is a noteworthy change in the state of an object. Because of this event 
diagrams must be tightly linked to state-transition diagrams. 



Driver reacts 
to police 



Driver begins to 
outrun police 



Driver stops 
for police ^ 



Police chase 
evading car 



Driver outruns, 
police 

> 



Driver 
caught 



Police issue 
ticket 



Ticket 
issued 



Police 
call for 
reinforcements 



Reinforcements 
respond 



to call C 



Driver 
goes even 
faster 



Driver 
gets away 



Driver 
caught 



I 
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When we create diagrams showing events, we think about the equivalent 
diagrams showing objects and states. Event diagrams are linked to state-transition 
diagrams. On the screen of a CASE tool, a change to an event diagram is linked 
to the corresponding state-transition diagram that itself relates to the object-struc- 
ture diagrams. 



THE LINKING 
OF OPERATIONS 



A model showing the behavior of an object-oriented 
system has many operations linked together, as shown 
in Fig. 9.2. 



Operations result in events. 

Events cause other operations to occur. 
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Invoice 
sent 



VCR User 
presses 
Rewind 
Button 



Rewind 
requested 



Rewind 
started 



Rewind 
completed 




VCR 
displays 
"Rewinding* 



VCR 
displays 
"Ready" 



Figure 9.2 

An operation may be performed by one class. The lines entering the operation 
often relate to the requests sent to that class. Sometimes, an operation is complex 
and needs expanding into more detailed event diagrams. At the lowest level of this 
expansion, one operation is usually performed by one class. One class has multiple 
methods that may be reflected by multiple operation blocks on event diagrams. 



CAUSE-AND- 
EFFECT ISOLATION 



Each operation carries out its task, regardless of what 
happens elsewhere. An operation is triggered by one 



Part II 



Chap. 9 



Events, Triggers, and Operations 



115 



(uivalent 
ransition 
is linked 
ct-struc- 



oriented 
s shown 



or moreevents, executes its method, and is expected to change the state of one 
object The operation has no knowledge of what event triggered it and why Addi- 
tionally, it does not know what operations are triggered from its event(s). In short, 
it does not recognize its cause and effect-^only that it is invoked to produce a 
state change of a given object. This isolation from cause-and-effect considera- 
tions is necessary for the operation to be reusable in many different applications 



An operation has no knowledge of what triggered it and why. 
An operation does not know what operations are triggered by its result. 
The operation is isolated from cause-and-effect considerations. 
This isolation makes it reusable in different applications. 



Order 
hipped 
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sent 
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PRECONDITIONS 
AND 

POSTCONDITIONS 



An operation has a precondition and postcondition. 
Preconditions and postconditions are of vital impor- 
tance in helping to ensure that a system operates 
correctly. 



Preconditions are those conditions that must be true before an operation can take 
place. 

Postconditions are those conditions that must hold when the operation is completed. 



If the precondition is not satisfied when an operation is invoked then the 
operation should not execute; it returns an error message. The postcondition 
describes the result; if it is not correct after execution then the operation did not 
execute correctly (see Fig. 9.3). 

Because an operation should have no knowledge of what triggered it or 
what will be triggered by its result, it should also have a precondition and post- 



Request 



Operation 



Result 



Preconditions must apply 
before the operation is 
executed. If the precondition 
is not satisfied the operation 
will not execute; it returns 
an error message. 



Postconditions must apply if 
the operation is executed 
correctly. Postconditions 
describe the correct 
behavior of the operation. 



Figure 9.3 Preconditions and postconditions are independent of where the 
operation is executed. 
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condition that are independent of where it is used. The operation is implemented 
in software as a method in a class. The method may be invoked by different 
applications. It can provide a service to multiple clients. In effect it has a contract 
with its clients saying that if they send a request for which the precondition is sat- 
isfied, then the operation will execute so as to satisfy the postcondition. 



The presence of operation precondition and postcondition rules is, in effect, a contract 
that binds the operation. The operation says: 'If you call me with the precondition 
satisfied, I promise to deliver a final state in which the postcondition is satisfied" [1]. 



A real-estate broker has a contract with its customers. The contract might have 
preconditions such as "I agree to pay the broker 6 percent of the purchase price if a 
property is purchased" and postconditions such as "A legal verification will have 



been made that the property has no encumbrances." This contract might be used by 
a broker for all of its clients, and the same contract might be used by many brokers. 

In 00 software design, a class, in effect, provides a contract to all potential 
users saying that if they invoke an operation with the correct precondition, it will 
provide a result satisfying the postcondition. 

The existence of this contract simplifies programming. The program for the 
operation is not required to check the precondition. It can assume that the opera- 
tion precondition rule is checked and is true before the operation executes. 
Meyer comments: 

One of the main sources of complexity in programs is the constant need to 
check whether data passed to a processing element (routine) satisfy the 
requirements for correct processing. Where should these checks be per- 
formed: in the routine itself or in its callers? Unless module designers formal- 
ly agree on a precise distribution of responsibilities, the checks end up not 
being done at all, a very unsafe situation or, out of concern for safety, being 
done several times. 

Redundant checking may seem harmless, but it is not. It hampers effi- 
ciency, of course; but even more important is the conceptual pollution that it 
brings to software systems. Complexity is probably the single most important 
enemy of software quality. The distribution of redundant checks all over a 
software system destroys the conceptual simplicity of the system, increases 
the risk for error, and hampers such qualities as extendibility, understandabil- 
ity, and maintainability. 

The recommended approach is to systematically use preconditions, and 
then allow module authors to assume, when writing the body of a routine, 
that the corresponding precondition is satisfied. The aim is to permit a simple 
style of programming, favoring readability, maintainability, and other associ- 
ated qualities [1]. 
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With an OO-CASE tool, it should be possible to point to an operation box 
and display its precondition and postcondition. 



CLEAR 00 techniques provide two important ways to divide 

MODULARIZATION complex software into simple procedures. First, meth- 
ods should result in. a state change in one object This 
state change, by itself, is usually simple and ts^j^^gjcami Second, each oper- 
ation is isolated from cause and effect. The operation can 1>e reused on different 
software and on multiple interacting processors. The precondition and postcondi- 
tion help to ensure its correct behavior. 

OO techniques thus provide clear modularization that is simpler and more 
precise than that of conventional structured techniques. Objects of great complexi- 
ije^sednvith^lalive^ as the use of a VCR. Com- 

jplex objects can interact in one piece of sbftware or on machines scattered across 
a network. Maintenance of software designed with OO techniques is easier than 
conventional software maintenance. 

A world of difference exists between this clear modularization and the 
amorphous jelly-like nature of most non-OO software. . 



CLOCK EVENTS 

drawn like a clock face: 



A special type of event is a clock time being reached 
that triggers some operation. This type of event is 



Operation 



/ — ( Change A 
( 4\ w North-South W__ 
\J*/>I Traffi c L '9hts W 
y to Green J 



Change 
North-South 
Traffic Lights j 
to Green 

}f fc Change 
East-West 
Traffic Lights, 
. to Red 



EXTERNAL Events are state changes that a system must know 

SOURCES about and react to in some way. Often, many of the 

,0F EVENTS operations that cause these events are external to the 

system. In these circumstances, the operation symbol 
is drawn as a shadowed box with round corners as illustrated in Fig. 9.4(a). 
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External 
Operation 




External Clock 
Event Type 



External 
Event Type 



Order 
requested 



Beginning of 
new quarter 



(a) 



(b) 



Figure 9.4 External operations are represented as round-cornered boxes with a 
shadow. When the event type is caused by an external clock, a clock face is used 

external process will emit clock ticks at some previously specified frequency, 
such as every second, the end of every day, the beginning of every month, or 
April 15th of every year. The event, then, is when the external clock tick occurs. 
External clocks are represented as clock faces. 

Two external events resulting from an external operation can be seen in Fig. 9.5. 



External 
Event Type 



Event Types Causing Changes of State in Objects 




External 
Operation 



Trigger 
Rule 



Invoice 
transmitted 



Figure 9.5 An event diagram showing operations and events that trigger oper- 
ations. The events may relate to a corresponding state-transition diagram. 
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TYPES OF EVENTS The 00 analyst does not wish to know about every 

event that occurs in an organization — only the types 
of events. Just as we talk about object types and instances of object types, so we 
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talk about event types and instances of event types. For example, the Waitlisted 
Booking Confirmed event type is the collection of those events in which an 
object changes from a Waitlisted Booking to a Confirmed Booking. 

Event types indicate simple changes in object state, for example, when 
money is added to a bank account or an employee's salary is updated. Fundamen- 
tally, event types describe the following kinds of state changes: 

• An object is created For example, an airline booking is created. 

• An object is terminated For example, a product is destroyed or a contract is ter- 
minated. 

• An object is classified as an instance of an object type. For example, a wife 
becomes a mother; a firm becomes a customer, an employee becomes a manager. 

-^Afr(to&t-h^dedassified-™ w instairce~of an object type. For example, a 



ceases to be a customer, a product is dropped from the sales catalog. 

• An object changes classification. For example, a lawyer changes from associate 
to partner, an account changes from a normal account to an overdue account. 

• An object's attribute is changed. 

Events can associate one object with another. For example, in most organi- 
zations when an object is classified as an Employee, it must be associated with a 
Department. Ohe event will classify the object as an Employee. A different 
event will create an association between the Employee object and a Department 
object. (Associations are objects like everything else, if named, ttiis ldhd of asso- 
ciation could be called the Employee-Department' Assignment ^bject'^^e.) If 
the Employee changed Department, a new Employee-Department Assignment 
would be created and the old one terminated 

Updating an account balance is another example of an ^yent When $10 is 
added to account number 14274, an event associates the account with a different 
value. 

Some events require other events to occur first. For example, before a 
Department can be closed, all of its Employees must i>e allocated to a different 
Department, the Offices it occupied must be allocated to a different use, and so 
on. 

Sometimes one event causes a chain reaction of other events. Changing a 
node on the screen of a CASE tool, for example, may require a set of changes to 
other objects in order to preserve integrity. Adding a circuit to the wiring of a 
jumbo jet may require mandatory changes to many objects. 



TRIGGER RULES When an event occurs, it usually triggers an opera- 
tion, as in the above diagrams; it may trigger multiple 
operations. The line going from the event to the operation it triggers represents a 
trigger rule. 
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Event Type Operation 



The trigger rule defines the causal relationship between event and opera- 
tion. Whenever an event of a given type occurs, the trigger rule invokes a prede- 
fined operation. In the following diagram, the event type Order Assembled has 
two trigger rules — each of which triggers an operation: 



I Assemble ^ 

I Order F-^L 



Order 
assembled 





( 


\ 




Ship 






Order 








/ 








V 




\ 




Transmit 






Invoice 








/ 



An event type may have many trigger rules — each invoking its own operation 
in parallel Parallel operations can result simultaneously in multiple state changes. 

A trigger rule invokes an operation and defines the necessary objects to be 
supplied to that operation. 





Here, the Order object from 
Accept Order is passed as an 
argument to the Assemble 
Order operation. 



Given the Task object from Complete 
Task, its associated Job object must be 
determined by the trigger for invocation 
of the Terminate Job operation. 



Trigger lines on an event diagram, then, indicate two things. First, they link 
the event to the operation that results from it Second, they determine the objects 
required as arguments for the operation that the trigger invokes. These lines, 
therefore, define the rules for triggering an operation when a particular kind of 
event occurs. Because of that, they are called trigger rules. 
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MULTIPLE 
TRIGGERS 

end of the month: 



Sometimes an operation may be triggered in multiple 
ways. For example, Produce Statement may occur 
when a statement is requested or automatically at the 



Chap. 9 



Events, Triggers, and Operations 



121 



Statement 
requested 




Statement 
produced 



In the following illustration, any one of the three events can trigger Esti- 
mate Modified Revenue. 



Br. 




Assess 

Monthly ^ > 
Sales 




Any one of these 
events may trigger 
Estimate Modified Revenue. 



Adjust 
Price 



Adjust 
Promotion ^ — 
Budget 



CONTROL The above operations are invoked by one trigger rule 

CONDITIONS (one event). Often, an operation requires multiple 

triggers to invoke it. For example, the operation Fire 
Missile can occur only if multiple conditions are obeyed: 



Send 
Firing 
Instructions 



Arm 
Missile 



"N Ins 

y 



Firing 
Instructions 
received 
> 



Missile 
correctly 
armed 



[ Enter 

Security fe» 
(Code J- 

Activate ^ 
Lock W 



Valid Security 
Code 
received 
> — 



Lock 
activated 
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The diamond in front of the Fire Missile block is referred to as a control 
condition 



Control 
.Condition 



Operation 



1 1 r"i 



The control condition must be checked prior to invoking the operation. (The 
diamond shape is similar to the decision symbol used in flow charting.) The con- 
trol condition can define a single condition or a complex collection of Boolean 
conditions. Control conditions are not necessarily just "and" conditions. They can 
involve elaborate conditions with "ands" and "ors": 
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mil) 



Control 
Condition 




IF the product is dispensed 
AND 

the correct amount of money has been collected 
AND 

the correct change has been returned 

OR 

the sale has been canceled 
AND 

the collected money taken has been returned 
THEN 

the sale is completed. 



THE BASIC 
CONSTRUCT OF 



Event diagrams are thus constructed from opera- 
tion blocks (see Fig. 9.6) and their connecting links as 
follows: 
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Book 
i Availability 
Determine ^determined 
Book 




Copy 
checked out 










Check in 




Copy 
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Close 




Book 




Request 



Loan 
completed 



Patron 
fined 



Figure 9.6 An event diagram for a library. 



SIMULTANEOUS Event diagrams often indicate that multiple operations 

OPERATIONS could be carried out at the same time. For example, in 

the following diagram Ship Order and Send Invoice 
could be done simultaneously. 

Simultaneous Invocation 
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Transmit 






Invoice 
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Simultaneous operations might be done on separate computers on a net- 
work. Much future computing will employ parallel (concurrent) processing. 
Design techniques are needed to indicate what processing can be done simultane- 
ously on separate processors. Event diagrams indicate when processing can occur 
in parallel. 
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Control conditions can also act as synchronization points for parallel pro- 
cessing. In other words, control conditions can ensure that a set of events is com- 
plete before proceeding with an operation. The control condition in Fig. 9.4, for 
instance, might state that Close Order cannot be done until the Order has been 
shipped and its Invoice paid. 

In models of business processes there are many operations that occur con- 
currendy. The model should show how they interrelate. 



OPERATION We have emphasized that objects and classes are sub- 

SUBTYPES AND typed. The subtype inherits the properties of its parent 

SUPERTYPES which leads to substantial reusability. 

In a similar way, operations are subtyped. The 
analyst should search for similarities in operations, so that the classes that per- 



-form the-operations canrinherit the sanrerdata and methods where possible; 

. Suppose that the operation Prepare Materials is followed by one of three oper- 
ations. The operations are mutually exclusive, that is, only one of them can occur. 

Mutual exclusivity can be represented by a branching line with a fiUed-in 
circle at the branch. As shown in Fig. 9.7, the circle looks like an "o" for "or" 
and means that the branches are mutually exclusive. 



m 



mv 



IS 



t 



Ml 

j/i 




Circle, like an "o" for "or" 
indicates that one and 
only one of the three 
operations follows. 

Figure 9.7 

To represent this better, indicate that each of the three operations is a sub- 
type of a general operation. In Fig. 9.8, they are shown in a partitioned box, as 
subtypes of Operation A. 

Here, Operation 1 , Operation 2, and Operation 3 all inherit properties for 
Operation A. This form of representation encourages the analyst to think about 
inheritance and reusability. It resembles the subtyping of objects illustrated in 
Fig. 7.4. This can lead to less redundancy — less code to design and generate. On 
larger scale examples, this can represent major savings and result in systems that 
can be changed more quickly. 
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Figure 9.8 
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EVENT SUBTYPES 
AND SUPERTYPES 



In a similar way, events are subtyped. This gives 
reusability of the trigger rules and control condi- 
tions. 

The following diagram shows two events resulting from the Review Task 
operation. 



Review 
Task 



Task 
accepted 




Task 
rejected 



However, only one of the events can occur when a task is reviewed. The 
two event types are mutually exclusive. It is better, therefore, to show one event 
type Task reviewed with subtypes Task accepted and Task rejected. 



Task 
reviewed 



► 

Task 
accepted 

► 

Task 
rejected 



The resulting event diagram is as follows: 
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Review 
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Task 
reviewed 



Task 
accepted 



Task 
rejected 
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As with the object-subt 



-evenusubtype- 



box indicates that the events in it are mutually exclusive. An event-subtype box 
(such as the object-subtype boxes in Fig. 6.8) can also indicate that other event 
subtypes might occur. 
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in motion 
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Figure 9.9 An event diagram for a car chase with event and control-condition 
symbols and with expanded event subtypes. 
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► 
► 



-Event typeX 
-Event subtype Xi 
-Event subtype X2 



' This area indicates an 
incomplete partition; i.e., 
there can be other subtypes 
besides Xi and X2. 
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coi?«?5<? ™ e operation that causes an event to happen may be 

complex. The operation that rewinds a VCR tape 
,™ un. .u -r appears sim P le — VCR user just presses one but- 

wL^ Cn ? Pe r6W ? Und eVCnt OCCUre ' user receives a s ^Ple message 
when the rewind is complete. However, internally, the rewind operation involves 
a whole set of operations and events, as illustrated in Fig 9 10 

Figure 9.10 illustrates a hierarchical decomposition of event schemas 
Boundaries can be placed around a complex event schema and treated as one 
high-level operation The lower-level event schema, then, becomes the method 
Jor the operation it decomposes. 

The events and operations that occur when the morning alarm clock goes 
ott and a person prepares for the day are shown in Fig. 9. 1 1 . 
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Operation Type Event Type 




;j Figure 9.10 Rewinding a VCR tape is a simple operation for the VCR user. 

However, a complex set of operations and events have to occur inside the VCR 
in order for it to perform the rewind operation. They define the method for the 

! rewind operation. Event diagrams may be decomposed hierarchically, like this, 

| making a high-level operation appear simple. 

OBJECT-FLOW Event diagrams are appropriate for describing 

DIAGRAMS processes in terms of events, triggers, conditions, and 

operations. However, expressing large complicated 
I processes in this way may not be appropriate. Often a system area is too vast or 

H intricate to express the dynamics of events and triggers. Perhaps, in addition, 
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It is generally true that the diagrams we draw should be designed so that code can 
be generated from them. An object-flow diagram is an exception to that It is a use- 
ful overview diagram. 



Object-flow diagrams (OFDs) are similar to data-flow diagrams (DFDs), 
because they depict activities interfacing with other activities. In DFDs, the inter- 
face passes data. In OO techniques, we do not want to be limited to data passing. 
Instead, the diagram should represent any kind of thing that passes from one 
activity to another whether it be orders, parts, finished goods, designs, services, 
hardware, software — or data. In short, the OFD indicates the objects that are pro- 
duced and the activities that produce and exchange them. Figure 9.12 is an exam- 
ple of an object-flow diagram. 
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Production 
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Materials 
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Assembled 
Computers 



Hardware 
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Figure 9. J 2 Object-flow diagram. 

A person familiar with data-flow diagrams will recognize the round-cor- 
nered activity boxes, the shadowed, external-agent box, and the direction of the 
flow lines. Absent here, however, is the data-store symbol. A three-dimensional 
box is used to represent real-life objects that flow between activities. 

OFDs describe objects and the way in which they are produced and consumed: 
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The product is the end result that fulfills the purpose of the activity. Products move 
to other activities that add value to the product — to produce another more complex 
product At every step, new qualities are created. In this way, the OFD can be used 
for strategic business planning as well as strategic information planning. 

Any activity may be expanded into more detail. For example, the high-level 
primary activity of a manufacturing company could be represented in more detail 
as shown in Fig. 9.13. 

Object-flow diagrams, then, can represent either top-down or bottom-up 
modeling. In particular, object-flow diagrams are very usefal in modeling organi- 
zations in a top-down fashion at the strategic level. Activities can be decomposed 
into OFDs. 

However, at a more detailed level in behavior analysis, expressing the 
dynamic aspects of event diagrams is more appropriate. An activity can be 
expressed in terms of an OFD or an event diagram, or both as shown in Fig. 9.14. 



ft 
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Figure 9J4 Each activity can be expressed as an object-flow diagram, an 
event schema, or both. 

The event diagram expresses a process in a more rigorous fashion that can 
generate code. To represent basic control structures and processing flow, and 
when the dynamics of events and triggers are not yet comprehensible, the object- 
flow diagram is useful. 
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goal of object^ be to £yoid prpgrainming 



Wherever possible, i 

easy ifor end users to understand and experiment with. 
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The desired behavior of systems can be described with the YMfy? of brides. 
Business ^policies, for example, can be expressed in rules such as the following: 

WHEN a customer has to average sales per customer 

THEN it is categorized as a good customer 

WHEN stock falls below reorder point for a product 

THEN only gdbd customers have their orders processed immediately 

WHEN n^ arrives 
IF orders are oh hold 

THEN orders are sorted by customer rating then earliest order date, and filled 
in that sequence 

WHEN orders are filled 

IF the customer is a bad payer 

THEN the order is put on hold until the amount due is received » 
AND the customer is notified 

RULES EXPRESSED Rules need to be rigorous sb that they;form a basis for 
IN ENGLISH co<de generation. However; it is ^^cM 

that rules are understandable 
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must be able to check that the rules correctly represent business policies and 
desired system behavior. Rules should therefore be expressed in English (or the 
national language of the end users). 

A typical rule expression in the language Prolog is as follows: 

sister (x,y) : - female (x), parent (x,z), parent (y,z) 

This is not likely to be understood by most end users. (It means x is the sister of y 
if x is female and if x has a parent, z, and y has the same parent, z.) 

When we use rules in object-oriented modeling, the rules can be expressed 
in English but at the same time be rigorous. English-language rules can be built 
with a rule editor that is part of an OO-CASE toolset. At the same time that the 
English is created, code is generated so that the rule can be executed immediate- 
- ly . The re s ult i ng English-may-be-clumsy-and t ed i ou s for en d users to compre- 



hend. When this is so, the analyst should write a more elegantly phrased sentence 
expressing the same rule. We then have both formal and easy-to-read English in 
windows which are linked to an OO model that end users can understand and 
work with. Their business policies are expressed in such a model, and code is 
generated directly from the business policies. This is done, for example, with the 
OO-CASE tool OMW, Object Management Workbench, from Intellicorp. 
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DECLARATIVE We can distinguish between declarative and proce- 

VERSUS dural languages or statements. 

PROCEDURAL Conventional programming languages are proce- 

STATEMENTS dural They give a set of instructions that a computer 

must execute in a specified sequence. The sequence 
may vary depending on conditions tested. Groups of instructions can be executed 
repetitively (loops). 

Declarative languages declare a set of facts and rules. They do not specify 
the sequence of steps (procedure) for doing processing. The computer uses the 
facts to derive a program for a particular procedure. The facts may be expressed 
in various ways. They may, for example, be in the form of a record: 
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Book 



Author 



Publisher 



Future Shock 



Toffler 



Random House 



Facts may be values that populate a spreadsheet. They may be expressed 
with statements such as the following. 

Pathogens associated with Gastrointestinal Tract include 



• Enterococcus 

• Clostridium Gangrene 
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• Bacteroids 

• Klebsiella 

• Pseudomonas 

• EGoli 

• Enterobacterium. 

• Proteus 



p*- .... 



^Facts may also be expressed with eqimtibns; f or example: 

\ PRINCIPAL = IN^^ 

(1 + INfTEREST_RATE/i 00) * * - N)^1^ INTEREST^TE/10d) 



■Mffffy tigee of the four variables in tins ^ are entered, .the. fourth 

be calculated. The user does not gwk^ cal- 
culation. Similarly, several simultaneous ^uatiqns could be used. ^ 

End users, who generally have programs and 

checking Aeir correctness^ can easily understand statements of facts and rules. 
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Declarative statements are much -easier* to, grasp and validate than procedural 
-language. "' ~" 

Where possible, we should build systems from declarative statements linked to OQ 
diagrams that end users can-understand.^ 



To a large extent, but not comple^ of an .OO system ; can be 

created automaticaUy vfrpm. facts and 
and code can be automatically gene^^ , . ^ 



MAKING BUSINESS 

KNOWLEDGE 

EXPLICIT 



The rules described in .this chapter capture the ; know- 
how about how tte lousiness or system should operate. 



Rules are encapsulated business knowledge. 



We need techniques with which business know-how can be captured, made 
explicit, made easy to read, and translated directly into executable code. With tra- 
ditional structured techniques, business policies, are not made explicit. They 
become buried in code written in COBOL or other languages. One rule is often 
reflected in multiple programs and may be virtually impossible to extract from 
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those programs by examining the code. When the policy changes, it is difficult to 
change the code or even to know what code ought to be changed. 



We need to make business policies explicit and translate them directly into code. 
When the policies change, it should be possible to regenerate the code quickly. 



Our challenge is to find diagrams that are meaningful to executives and 
business people, that enable such people to visualize how their enterprise oper- 
ates and to help redesign it where necessary. An OO-CASE tool should enable its 
users to navigate through the diagrams and expand windows that show the rules. 



Collectively, the OO diagrams and rules should represent the laws about how the 



i 



m 

W 



business is run. 



With traditional structured techniques, there is a poor translation of business 
policies into programs. With OO techniques and rules, we want the most direct 
translation of business policies into generated code. When business policies are 
changed, we want that to be reflected quickly in regenerated code. 



RULES LINKED 
TO DIAGRAMS 



We have emphasized the value of OO-CASE tools for 
OO modeling, analysis, and design. CASE tools use 
the diagrams described in Chapters 6 to 13. Rules 
should be associated with these diagrams. The CASE tools may show them in 
windows linked to the blocks or symbols on the diagrams. 

Some rules are associated with the diagrams used in Object Structure 
Analysis (described in Chapters 6 and 7): 

• Inheritance and subtyping diagrams 

• Object-relationship diagrams 

• Composed-of diagrams 

• Diagrams showing data structures 

Other rules are associated with the diagrams used in Object Behavior 
Analysis (described in Chapters 8, 9, and 13): 

• Event diagrams 

• State-transition diagrams 

• Diagrams showing methods 



categories 

PI, ;; :jOf:rules 
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Several different types of rules exist. Business rules 
can te cl^sified. as, integrity rules;, derivation rules, 
arid behavior ruifes [2] . ^ - v i':* : ; 



Rule 



Integrity 
Rule, . 



Denvation" 
Rule; -\[ 



: .Behayipr r . 



Integrity rules state that somethjng i^ For example, a yalu^must 

|||^widmi ; a certain range, an Qjbject relatif^ 

v pr^onditipn must hold before an pp^ticm is^ (6x^u^li arid so on. Operation 
%^^ co ^4p^ m \ es anitl operation postcondition rules ^^im^iimr&^^d^as^ 

^l^^t^^es: . ' ' ; " ; v v'^-'"- ■ - -v^-i^; ■-, ^ ; 

■ : Intep^ ruleVihould start WitS ^pHrasfe '"it sh(^a*aiway^l^ld thaffiBcxx 
10:1 gives some examples of integrity rules; -■■.^■^ : ---^ x - nr . .. v.- 

I;. Derivation rules state how a value of a; set of values is computed. B<^10.2 
f gives examples of derivation hiles. ' ' >; t;vv \ • <vv -' " ^ 
V.j^y Behavior rules describe dynamic aspepts, of b^havionl They are conmioi?iy 
> event diagrams. They-^ del|ribe 

r ^at cbnditi M ! 

> In some methodologies, cardinality constraiiits%e f^rred^to as ''business 
rules" and are the only form of business riile; These should be referredlio as 
"cardinality rules" to indicate that they are : only one narrow type of business 
rule. ' v 



wm STIMULUS/RESPONSE 

tti^RULES 



Stimulus/response- rules express triggering behav- 
ior and generally have the form 7- 



pip' 



WHEN <event> 

I F <cpndition to fulfill> 

THEN <operation> 



m^Mlk*ii business model this can be 



137 



BOX 10.1 Examples of integrity rules. 



These are easy-to-read versions of rules, which are in more formal 
English when created by a CASE rule-builder. The same applies to 
Box 10.2. 



IT MUST ALWAYS HOLD THAT 

The number of employees is less than 1 ,000 

IT MUST ALWAYS HOLD THAT 

The number of employees who are managers and earning a salary greater 



th a n 100,000 i s l ess t h a n o r eq ua l to 3 — 

IT MUST ALWAYS HOLD THAT 

The number of hotels (with the same hotel name and located in the same 
resort) is less than or equal to 1 

IT MUST ALWAYS HOLD THAT 
A manager is not a secretary 

IT MUST ALWAYS HOLD THAT 
IF an employee has a company car 

THEN this employee does not receive a monthly transport reimbursement 

IT MUST ALWAYS HOLD THAT 
IF an employee works on a project 
THEN this employee works for a department 

IT MUST ALWAYS HOLD THAT 

IF an employee has a marked parking slot 

THEN this employee has a company car and is a manager with a salary 
greater than 60,000 

IT MUST ALWAYS HOLD THAT 

IF a flight is scheduled to depart from City C 
THEN this flight is not scheduled to arrive in City C 

AFTER modify of salary of an Employee.E IT MUST HOLD THAT 
The new salary of Employee E is greater than the 
old salary of an Employee E 

IT MUST ALWAYS HOLD THAT 

The age of an employee is less than 65 

IT MUST ALWAYS HOLD THAT 

The sum of salaries of employees working for 
Department D is less than 0.6 * budget of Department D 
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BOX 10.2 Examples of derivation rules. 



ter 



tfefeSf 
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PRODUCT.NET_PRICE = PRODUCT.PRICE * (1 + TAX^PERCENTAGBIOd); > 



as I 



Invoice.Total = Sum of lnvoice.Line^totals;+ Sale^tax + Seryice^charge- 



WHEN lnvoice;Net_total > 0 and < 2500 



"Taxes = lnvoice.fiet_total * 0. 1 5 

ELSEWHEN Inybice.Nertotal >2&Dp and < 50000 • 
taxes = (InvoiceiNet^total - 2566)* 0. 1 8 - 3750 

ELSEWHEN lnvoic^:Net_totaL> 50000 and <75000 
Taxes- (Invbibe.NetjotaJ - 50000) i* 6.36 - 8250 

ELSEWHEN invoice. Net^total > 75000 and < 100000 
Tax^ (iriyoice.NeOtotel 756opf * 0 :46 - 1 5750 

ELSEWHEN lnvoice.Klet_totaJ > 1 

Taxes= (Invoice.NeUtotal - 1 0(X>66),* 0.46 - 25750 

IF ; Symptom_or Problem is equal to ^biscuits pale" or 
Symptom^or Problem is equal to ^is^uits not risen" 

THEN set HypothesiOLProblem to Iqw 



IF a customer has bought more than twice average sales per customer for the 
last 12 months 



THEN classify customer as a "Good Customer* 



THEN give priority to batches containing items for a Good Customer 



items for a Good Customer 



mi'-- 
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WHEN an event happens 
IF a condition is fulfilled 

THEN do something 



In a technical system, it can be 



view 
conti 

oper. 
straii 



ON <stimulus> 
IF <condition> 
THEN <response> 



In these expressions the IF clause is optional. 

This form of expression relates to the basic construct of the event diagram: 
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In cc 



Event Trigger Control 
Type Rule Condition Operation 



WHEN and IF 



THEN 



Such stimulus/response rules can be expressed rigorously but can 
also be translated into an English statement that end users can validate. For 
example 

WHEN Account is posted to Sales Ledger 
IF Customer is of type D 

and Balance has been negative for 1 8 days 
THEN set Status to Credit Stopped. 

The THEN part of a rule is an operation. For example, set Status to Credit 
Stopped is an operation. Often, however, the THEN part of a rule invokes an 
operation by name. For example, when a stock item falls below the reorder point, 
send a request to Reorder the stock item. 



OPERATION 
CONDITION RULES 



As commented in the previous chapter, each opera- 
tion has its own context-independent precondition and 
postcondition. Preconditions and postconditions 
should be expressed with rules that end users can understand and verify. These 
rules are of vital importance in helping to ensure that software operates correctly. 
Bertrand Meyer states that the presence of these rules in a routine should be 
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• viewed as; a contract that binds the routine and its callers [1]. It is* in effect, a 
contract relating to softw^e, reliability. . 

Operation precondition rules express those constraints under which an 
; operation will perform correctly. The operation cannot go ahead unless these con- 
^^^■■.straints are satisfied. Operation. precondition 1 rules have the form 



wmr 



Order a Product < t ^ - • 

piSILy IF there is an authorized Supplier offering this Product 

Promote Staff Employee to Manager 

ONDy JF Emplpyeerh^a Ste^^ -r.v, > ; r 

: and Employee is?nMa^M^g^r >. ; , . • r : ; 



^ but can 
date. For 



to Credit 
ivokes an 
der pbint, 



:h opera- 
iition and 
mditions 
fy. These 
correctly, 
hould be 



guarantees the results. It 

says that when the operation is execu 
■^^SS tibn postcondition rules Hav^ 



ONLY IF the Product Oi^ 



ON LY I F Employee is riot in a Staff position ^ 

and Employee is a Manager / ^ > 

Events are those state changes to which a system must react 

(represented, by a black triangle), reflect an. aspect of an ogeratioh ^stcondition 

rule. When that aspect is true, the event occurs: -^y :■■■■■■<•• •'"^•'■•r ; t ' - 



The postcondition . 
relates to the event 




CONDITIONS Before an operation can be execute ^o things must 

'FOR EXECUTING be true: its pr^bniUtion; which is 

AN OPERATION particular application, arid its control ^ 

is dependent of the application. Both of these are 
expressed as rules. ' " v;v '■■ r ■ '■• v ■■ : r» 

The user of an OO-CASE tool should be able to point at the control condi- 
tion diamond or at the operation box and display the control condition rules or 
the operation precondition rules. - 5 
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Postcondition 




\ 

Operation 
Precondition 



Control Condition 



The control condition relates to the trigger rules and is often designed to 
achieve correctness of the precondition. 

These rules, displayed in windows on the event diagram, should reflect how 
the business people want to run the business. Business policies are explicitly stated. 



ft 



0- 

I 
in 



ft 



3 i 



! : ! 



EXECUTABLE The event diagram, including statements of rules to 

DIAGRAMS express preconditions, triggers, control conditions, 

and the calculations or transformations done in an 
operation, is an executable diagram, that is, it can be converted to program code. 
The operation itself may be expressed declaratively or in a form that can drive a 
code generator. 



An event diagram with rules is executable. 

The diagrams of traditional structured analysis are not executable. 



The most useful form of an OO-CASE tool , is one that generates code 
immediately from diagrams that are executable. The code can be immediately 
executed to see whether it is doing what the designer intended — rather like a 
spreadsheet tool. When you create the columns, rows, and calculations of a 
spreadsheet, you can immediately run it, then quickly change it, and rerun it. You 
can experiment with it, adjusting its design. 

An OO model is likely to be much more complex than a spreadsheet but the 
tool should make it equally interactive. You should be able to build it and immedi- 
ately run it, add instances of class data, and observe its behavior, grow it, and 
change it quickly. You should be able to experiment with your design as you build 
it 

At first, the code will be generated interpretively and need not be machine- 
efficient. Later, when the design works well, it can be compiled and perhaps 
redesigned for maximum efficiency. 

The ability to run the design immediately, experiment with it, and 
change it, greatly increases creativity. It expands our ability to invent interest- 
ing software. 



RULES ATTACHED 
TOOTHER 00 
*M:W DiAGi RAMS 



Rules can be linked to other types of diagrams as well 
as event diagrams. 



Rules can be attached to any, of the diagrams in the previous chapters.: 



ipr Examples, of rules associated with, the diagrams of OO analysis are. shown iriiBox 
^PI^A^v^H 1 ^^ can be- divided into two t^ iiiles and pbj^tTbeMyior 

^^jciited with ^agrams, such ^ fe^®^ 

^ l -^^i-b^avior analysis. Most are ^sqciate^i wiUi the event diagiW; s^mfe are 



^ jfig^ 10:1; sto thSm, as 




life 



•Figpe 10.2 shows a rule wind9w ]^ed,to^ 




^^Jups^^pie ^adj^st caii mmiidmtely 'ran'hijs/mbd^ 
*|||^ from ic He can ^us irr^ 

^^rf^el/Thef business' people using the tool,;possib^ 

^^^^j'later), can try out different busiries:^p6lities &&6$s&rtk tfi^ir ^^gfiiey 



;can 



§?p;THERROGRAMMER 
ASmWYER 



The English expr^ eripugh for 

code generation; is fom difficult for 

™ ., r , . .. t business, peopledojrie;^ 

uanslate the executable mles into e^y-tcnread Baglish. ? 
^fc f . The bottom box of the Rule Editor jPrf^ 
^^g^foimal- English. The box above, labeled "Meaniiig," c6^ 
^^§^0^^^i^JSt ^the* same rale;T^: 

^mment^' about who wants the business policy . that the rule represents, or why it 
iis used! : _ 
^^'f^^JHgiife -1:0.3 -shows three more mle ^^d^ 
im in'OO diagrams. The red item in ^ch di^ 
^^^tfi^is 1 ;!^^ wth the tool's rul^builde:^ 

; ^ e '^ le il simultaneously generates exkutable ^ 
|Kfcompo^ an easy-to-read version of thfcnile in the box labels "Meaning. v 
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- : r ffi^fc«havior^ «f • ^ the model, the effects of their policies, arid the possibilities for 
business process redesign. 

? With this approach, business people can express their business policies in 
, normal English/The analyst, rather like a lawyer, translates this into;pi^ise Eng- 
glish and corresponding code. :When the business people chan^ i|pplicy,; this 
?|ange xan be translated, directly and quickly into software that?ii^^meriteihe 



THE INFERENCE In the 1980s, artificial intellige^e%stems, became 
ENGINE highly fasWonable.; The primary mechanism of such 

- H : systems buUttin the^l980s was ari inference engine. 

^ An inference engineuses a collectibn df facts andMes&fout a spec ific' area 



of taowleflge and makes deductions using the technique^ of lbgidal inference: It 
?^«spond to ;a request |>y seating- rules |rid firing Ad^effectively fining 
^th^^ules together to perform inferenti^frfa^pning. It jti^ifceS fciwanl chaining 
^ihjpm^l^ted reasoning), backward chainii^|goal-5^ 
It enables a computer to make complex deductions withcmt^pmmere having 
5tp code an application. / * ^ ^ 

; ^ concept of the inference engine was used to buMe^ert systems. Expert 
^systems store knowledge culled for an expert in the f^^Mts and rules and 
^^^^tions r by employing an inference engine.^ 
IRU^give ^vice like a human. expert in a specific .irano^^ 
C : The rules that an inference engine chains together to make^deductions are 
called production rules. The rules referred to in this chapter are generally not pro- 
eduction rules. They are rules that are linked to OO diagr^ 1m Artier to generate 
toeaningful.m code. - T t ? { P"! 

g;. An inference engine, like any other computing t&hniquepinay^ be^ed to 
inclement methods in a class. Usually, this; requires ^ :^// ^ rules 
eraiSier than the large rule collections that characterize some ^tifid^^mtaiigence 
^systems. Each method makes a relatively simple change :tb tlie data jn the^class. 
Because it uses a small . collection of rules (usually fewer thai^MWptoan be rela- 
tively fast and efficient. ; "■ ' ' '"' • ' : 

• Some expert systems were built with a large number of rules. There was an 
UKthought-out notion that if an inference engine could use a vast collection of 
niles, it, could solve formidable problems. Sdme early expert systems used more 
than 10,000 rules. Large amorphous collections of rules present two problems. 
First, machine performance is bad. Inferencing ^ algorithms do not scale up efficient- 
ly when there are thousands of rules. Second, it is difficult to tell what the inferenc- 
ing system is doing and hence it is difficulty debug it Changing the behavior of a 
rule-based system is very easy, in principle. One simply changes the rules— which 
;s much easier than changing a COBOL program. HoweVer, its behavior is difficult 
to understand if the collections of rules are large and unstructured 
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Ru£ .-r j Peats 0 Save 1 | Revert] ■ | Delete | 
,*, y w ' Stock Op tion n_helit_ t> y ' ^ * 



Typ« 



Deiivstlou Rule 



Indicate authorship and date of this rule, 
or other- useful information here.' • 



TT MUST/ ALWAYS HOLD THAT 

stock optiorts can only be granted to managers 

who earn mbnT than 90,000 



FtdationshtpValue Constraint 



IT MUST ALWAYS HOLD THAT, if Stock Option is_heW_by Employee 
then EjtipjoyWTa a Ma^^ more.than 90000) ' 



Ride: . {Create) j Save | v [Revert \ / iDetete] 
brvo*ca.Taxe* 



l*IJJH.MMJ:M« 
Integrity Rule V 



This computation' has not been approved by the tRS. 
Any representation to the contrary is a criminal offense. A 



1 Options Rule Edit 



AttributeValueRiile 



DERIVE tnvoice.Taxes AS FOLLOWS: - IF, lnvbice.Tdtal ts~betmeen 0 
and 25OO0 it is (a 15 * Invoice.Total) ELSE it is (0.2 • 
InvbieeVTottOi^v ; r* f ' V >'■ " " 




Indicate authorship and date of this rute, 
or other useful information here. 



fT MUST ALWAYS HOLD THAT ,% . 

bad customers can place at most 10 orders 



n* MUST ALWAYS HOLD THAT Customer that has a Behavior equal to 
Bad places not more than 10 Order 



Figure 10.3 Three examples of rules built 
wim the OMW rule editor and attached to var- 
ious' parti of OO diagrams. The formal rules 
are in red. The easy-to-read version of the rule 
is in the box labeled "Meaning." (Courtesy of 
IntelliCorp.) 
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Models and Diagrams 



Part II 



Just as traditional programs, repeatedly added to, become great rolling 
snowballs of code, which are murder to maintain, so large expert systems grew 
into vast collections of rules that became difficult to understand. The answer to 
both situations is design in an object-oriented fashion where the classes have 
methods that are relatively simple and the overall model is easy to understand. 

The artificial-intelligence community developed frame-based techniques for 
designing expert systems and representing knowledge. A frame is essentially an object 
It has packets of rules associated with it that are used with an inference engine when a 
request is sent to the frame. Some frame-based software for building expert systems 
evolved into object-oriented toolkits with methods, inheritance, and encapsulation. 
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UNNECESSARY 
RULES 



The early expert systems used a large bucket of rules 
in which the inference engine went fishing for rules to 
use. Most of the rules in these early systems are 
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unnecessary when object-oriented design is done. They represent information 
that should be affiliated with OO diagrams, such as object-relationship diagrams, 
composed-of diagrams, state-transition diagrams, and event diagrams. For exam- 
ple, cardinality information on object-relationship diagrams and the information 
in normalized data models were represented as production rules. They should 
have been quite separate from the production rules. 

To assume that all knowledge should be represented by production rules 
was a simplistic viewpoint that led to severe code inefficiencies and systems that 
were difficult to debug and evolve. 

OO analysis has a different viewpoint. Rules and other declarative state- 
ments should be associated with OO diagrams so that the diagrams are exe- 
cutable. Most of these rules are not used by an inference engine. Sometimes, one 
method does employ an inference engine, just as a method could be implemented 
with any other computing technique. When this happens, it is usually done with a 
small number of rules (often less than 100) and so the inferencing is fast. 



VISIBLE AND 
NONVISIBLE RULES 



Some rules need to be visible to end users so that 
they may check them in a workshop (Chapter 14). 
These should be in English, perhaps with detailed 

comments. 

Other rules are for I.S. professionals and need not be seen by end users. 
These include certain integrity rules and rules for technical design. 

Yet other rules are internal to the OO-CASE tool and the facilities that 
ensure integrity and consistency in its repository. These rules are part of the basic 
tool design and need not be directly visible to I.S. users of the tool. 

We should distinguish these three categories of rules (Box 10.4). 

Box 10.5 gives other examples of rules which business people see as part of 
the OO enterprise model. 
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TRACEABILITY Each business policy should be directly tra<&a£>ll 

from the" business people who help: establish the^rules 
to the code that is generated from them. 

Traceability may begin in an end-user workshop in which the policies are 
established or reviewed with the business pdbple most familiar with the mJojcct 
area. In such a workshop, each rule is expressed both in fbririial >aiid ^y-^r£ad 
English. Comments may be recorded about ffie^ m to state why it is u|e£, t o 
establish its business context, or to indicate ^hen it sliould • fee reexami^d.^ 
CASE tbbi for 00 analysis ought to i&i^sp^ 

ken comments can indicate why the rule was established ami whtf Was responsi- 
ble for it. At a later time, the spoken comments might be reviewed anct^ome 
rules refined or replaced. 

To trace the effect of rules, an interpretive code generator is useful that imme- 
diately generates code and allows tables to be populated with instances (6f the 
objects and their data. This allows an analyst .to check with end users in a work- 
shop that the system, or a piece of the system, is working as intended. The inter- 
Feted code grows and is refined. Eventually, it will be compiled for eflSciency. 



-CHANGING 



HOW BUSINESSES 



The ability to translate policies directly in executable 
code has th^ changing the way businesses 

are run; just as&plant cbntroll&r cai^turn a valve and 



BOX 10.5 



Examples of visible rules. 



Examples of rules that business people can validate and change. All 
such rules appear in windows on the OO-CASE diagrams. (From 
IntelliCorp's OMW.) 

Banking 

If LiquidrtyRatio < 1 then Liquidity is bad 

LiquidityRatio = ShortTermAssets/ShortTermLiabilities 

ShortTermAssets = CashinHand+AccountsReceivable 

"ShortTermLiabilities = BankLoans+AccountsPayable 

When ReviewLoan is completed 

If MonthlyRepayment <= 10% of MaximumRepayment 
then GrantLoan 

When ReviewLoan is completed 

If MonthlyRepayment > MaximumRepayment 
then RejectLoan 

When ReviewLoan is completed 

If MonthlyRepayment > 50% and <= 100% of MaximumRepayment 
then SeekGuarantees 

When ReviewLoan is completed 

If MonthlyRepayment > 10% and < 50% of MaximumRepayment 
then ReviewSituation 

Car Rental 

On ChecklnCar 

MileageUsed = MilesReturned - MilesOut 
GasUsed = 1 - GasGaugeReading 
DateReturned = Today 

When ChecklnCar is completed then CalculateCharges 

On CalculateCharges 

RateCharge = (HireRate)*(DateRetumed - DateOut) 
GasCharge = GasUsed*ModelRefuelCharge 
TaxCharge = (RateCharge + GasCharge)*StateTax 
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:BQmO^(0pntinued) 




. adjust a manufacturing process, so -business, people may in the future be able 
to : modify rules of the business and make a direct change in the automated 
^|;VV c operation of the business. They will adjust and try to optimize how the business is 
conducted. 
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Models and Diagrams 



1. Meyer, Bertrand, Object-Oriented Software Construction, Prentice Hall New 
York, 1988. 

2. Van Assche, Franz, Rule-Based IEM, James Martin and Co., internal paper 
December, 1991. 
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I Applied 



Application 
.received 




Application 
rejected 



j Rejected ^ 



and Class 
full 



Add to 
Waitlist 



j Registered j 



. Waitlisted . 



Register- 
Student 



Local Student 
registered 



Remote Student 
registered 



Invoiced 




De-Waitlisted 



Get 
Dormitory 



Removed for 
cancelation 







Accept 




Payment 





Paid 




Payment 
accepted 




Figure 11.9 An event diagram for the process of registering students. The 
states of the Student object are shown on this diagram. Figure 1 1.8, showing 
the state changes in this diagram, can be generated automatically from this 
diagram. 



State-transition diagrams may be shown as windows that are opened over 
f|; 'event diagrams. Figure 11.10 shows two state-transition windows opened on the 
* event diagram of Fig. 11.9, with color showing the state of the Student object 

jjttype. 

Conversely, Fig. 11.11 shows a state-transition diagram and a window con- 
staining an event diagram corresponding to one state transition. 
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vis the kind of service requested, and the method is the specification of the pro- 
gramming code for it , ' • 



An operation is a process that can be requested as a unit 
A method is the specification of an operation. 



The methods in a class manipulate only the data structure of that class. They 
cannot directly access the data structure of a different class' To use the data struc- 
tures of a different class, they must send a request to that class. Encapsulation 
must be preserved^in OO design. 

The designer takes an operation on the event diagram and adds more detail 
to it in order to create a design. For example, a model produced in analysis may 



contain the operation Create Purchase Order. 
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Along with this, Object Structure Analysis has identified object types, such 
as Supplier, Purchase Order, and Product. 
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Data modeling has identified the attributes that are required for each of 
these objects. The attributes are associated with the object identifier in a correctly 
^normalized manner. One object may have multiple normalized grpups of attri- 
butes (i.e., it contains multiple entity types). 



CLOCK EVENTS 

drawn like a clock facer 



A special type of event is a clock time being reached 
that triggers some operation. This type of event is 



Operation 



^SmI^JL* S ° me °P erati P ns can °nly take place when certain 

CONDITIONS conditions apply. These are called control conditions. 

Control conditions are shown with a small diamond at 
tjje front of an operation box: i 
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The diamond shape is similar to the decision symbol used in flow charting. 

The control-condition diamond can define a single condition or a complex 
collection of Boolean conditions. The CASE-tool user should be able to mouse- 
click on the control-condition diamond and display a window showing the 
conditions. 



TRIGGERS A line going to an operation box indicates that the 

operation is triggered by the occurrence of a preced- 
ing event The trigger may have a rule associated with it. 

An event can trigger multiple instances of the same operation. A one-with- 
many crow's-foot notation can be used to indicate this: 



Go to 
DEFCON2 
Alert Status 



> 



/ 



Dispatch 

B52 
Bomber 



Cardinality 
Symbol 

The trigger-rule line indicates the association of an event type to the opera- 
tion invoked. Additionally, it can indicate the way in which the necessary 
objects are supplied to the operation it invokes. In this way, the trigger rule 
defines a causal relation between event and operation— as well as a form of 
"data flow." 
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Figure 17,1 illustrates an example of the ADT named Employee. At its 
heart, the ADT is defined by its data structure representation. For Employee, this 
includes data about exemptions, position, salary amount, phone extension, and so 
on. The ADT is also defined by a set of permissible operations. These opera- 
tions—such as hire, promote, and change phone extension— provide a suit of 
armor that protects the underlying Employee structure from arbitrary and unin- 
tended use. In other words, the Employee operations provide the only method of 
accessing and maintaining the data of an Employee. 



Abstract Data Type (ADT) 



Promotion of 
an Employee 



Request to return a 
list of all 
management 
Employees 



Permissible 
Operations 




Request to change the 
phone extension 
of an Employee 



Data Structure 
Representation 



Figure 17. 1 Objects arc accessible only by nam^d operations; all else is WddciL . 

Additionally, each method ot processing dgorithm, employed to carry out 
an operation, is hidden from its usere/ What the user^^ m is an appropri- 

ate object to request the operation "along" with any appUc^Ie supporting parame- 
ters. For example, Fig. 17.2 depicte tl^ in 
order to give Bob a, promotion, the request must specify Bob; the promo opera- 
tion, and the salary grade of his promotion. In its abbreviated form, this request 
could be written: Bob, promote, director. 

Objects as Encapsulations : 

Figure 17.2 depicts three Employee objects as specific representations of the 
Employee ADT. In this way, an object can be regarded as any instance of an 
abstract data type— each encapsulating its own private data and its own permissi- 
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Laura 



Object 

/ Give Bob 

' a promotion 




Figure 17,2 An object's permissible operations are defined by its ADT. 

|ble operations. Each object can be considered as a thing in its own right, with its 
jgwn behavior. While each object should encapsulate a physical record of its own 
ata, encapsulating a physical copy of each operational method is unnecessary " 
ad wastefiiL Since the same coding is contained within each ADIVan ADTs 
perations need only be virtually available to an object In other words, all opera- 
Sons that apply to a particular ADT also apply to the instances of that ADT. As 
lustrated in Kg. 17.3 f since Bob is an instance of the Employee ADT, 
inptoyee operations (such as promote) also apply to Bob— ^thout'the object 
having to contain them physically. When an object is an instance of an ADT, this 
* 'age is established. Most ADT-oriented languages accomplish this with a 
sical pointer mechanism. 



EOBJECTS With encapsulation, each object need only know what 

fAND REQUESTS it can request of another object, because operations 

are the public interface for all objects. AH the 
specifics of how its structure is stored and how its operations are coded are 
tucked neatly out of sight This not only protects each object, it simplifies the 
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All Objects are linked to 
the Abstract Data Type of 
which they are Instances. 




_ FigureUJ Eyc^y ADTis linked U> Its j^** 110 ^* ^ 1. " 1 1'. 

interacdons among objects. Most OO languages call these i^^o^ messages. 
For instance, a Customer object Sff^i«"WJO.f P^er object to a&a 
product to its already existing line item*. The Order object, in » may, sq£.« 
message to a Customer Account object with a request to update the amount dxxt 
for the customer. - ..... - . 

The standard term emerging for emerge* a request (Fig. 17.4> A req^ 
is a more general notion, because more than one object can parhcipate **™mL 
For instance, to which object is amessagc*cnt «r ^^P^"?.* 
Bin: the Partorthe Bin? A request involve* both by sr^ing the Partafl*f in 
objects as parameters along with the operation name. It then lets the method selec- 
tion mechanism locate the appropriate method for placing mventory In short, 
requests expand the notion of message by indicating: With these objects, do this. 



INHERITANCE AND 
POLYMORPHISM 



Inheritance h «n important feature of OO design. 
While different OO programming languages havodif- 
ferent inheritance mechanisms, we can think about 
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Figure 17.4 The operation of one object requests the operation of another. 

them in the following way. When a request for an operation goes to a subclas^ 
he list of permissible operations of that class is checked- If the operation is 
bund on the list, it is invoked; if not, the parent classes .^e^^ 
operation. 

An important feature of inheritance is the ability of a class to overrule 
erited features. Here, the processing algorithm, or method, of an inherited v 
^operation can be redefined at the subtype level The example in Fig. 17.5 illus- 
three classes. The most general, Polygon, contains the data structure and : 
ible operations for polygons. Because every instance of a Rectangle is 
an instance of a Polygon, the Rectangle subtype need not repeat those fea^ 
!tures it inherits from Polygon. However; while all Polygon operations apply to q 
types, the method of operatioinnay be different For example, die method of. 
tating a Polygon is the same as rotating a Rectangle. However, the method of 
^computing perimeters may differ. The perimeter of a Polygon is the sum of all its 
sides; the perimeter of a Rectangle is the sum of two of its adjacent sides multi- 
plied by two. The Square perimeter differs again as the product of multiplying 
four times the length of any one side. 

Whenever a request is made for an operation on an object, the method 
selected depends on whether or not the inheritance hierarchy has been overrid- 



M 



Same inherited operation; 
different method selected. 




For this object (which 
happens to be a square), 
compute perimeter. 



Figure 17.5 Inheritance can be overrid- 
den. A subtype may have its own version of 
a method. The subtypes Rectangle and 
Square have their own methods for Com- 
pute Perimeter. 
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i dea. The method for moving a Square three centimeters to the right is selected 
\ from Polygon. However, even though the operation for compute perimeter is 
; inherited from the Polygon, the method selected for a Square is located in the 
: Square class. This approach to overriding inheritance properties through redefin- 
ition is often referred to as a category of polymorphism known as parametric 
\ polymorphism [2]. An operation, then, is the kind of process being requested Its 
method is the specification of how to cany out the operation. 



CANCELING Some expert systems in AI allow some inherited fea- 

^INHERITED tures to be canceled For example, one of the features 

^FEATURES of Birds includes flying. However, this feature does 

not apply to Penguins and Ostriches. Therefore, this 
feature can be canceled The arbitrary overriding and canceling of inherited fea- 
tures is a questionable practice* Logically it is incorrect, because, by definition, 
all features of a type apply to its subtypes. Therefore, to rectify the problem of 
iBIftirflying andPengulns notTtfiesuBtyping hierarchy needs to be changedrTo - 
jsolve this, Bird can be specialized into two subtypes: Flying Bird and Nonflying 
[Bird. Following this, all the data structures and operations relating to flying 
|should be shifted from Bird to Flying Bird. Types such as Penguin and Ostrich 
* liould then be realigned as subtypes of Nonflying Bird- This , would correct the 
logical inconsistency. However, physically it might create an intolerable system 

Dverhead For this reason, some languages allow the programmer to deviate from h 
at is logically correct — for the sake of performance. 



[CHARACTERISTICS 
EOF 00 LANGUAGES 



To be described as an OO programming language, a 
language must support - - . .■•■„>.- 



• Classes and encapsulation. Each class has certain kinds of data. Each class pro- 
tects its data from improper use by offering a number of permissible operations. 
To accomplish this, both die data representation and its permissible operations 
are veiled with a protective covering that hides the details of its in^lcmentatiorL 

• Method selection. With method selection, the user need only specify whiciT 
operation should be applied to an object (or in more expanded languages, one or 
more objects). The system will thai choose die method appropriate for the spec- 
ified parameters, in other words, the user only needs to specify what is to be 
done, and the method selector determines how it is to be applied ^Polymoirphism 
is one of the common applications of method selection. 

• Inheritance. Classes inherit the data types and methods of higher level classes* 
Inheritance allows systems to be constructed from existing class hierarchies. It 
provides mechanisms for both construction and reuse of software. In this way, 
we do not have to reinvent the wheel — only the portion of it that is different 
Inheritance imposes a mechanism on classes that greatly reduces the complexity 
of the resulting systems. 
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Some OO languages support multiple inheritance; others support inheri 
lance from only one parent class. 



PURE VERSUS Some OO languages have been designed specifically 

for 00 Programming with objects, encapsulation 
LANGUAGES method selection, and inheritance. Smalltalk was the 

first language developed purely for OO programming 
Following Smalltalk, Actor and Eiffel evolved as pure OO languages. " 

Other languages used for OO programming are traditional languages that 
have had thfe capability added to them to handle objects, method selection, and 
inheritance. These are referred to as hybrid languages. The preeminent hybrid 
language C++, an extension of C, is currently the most commonly used language 
for OO programming. C++ uses a preprocessor that converts C++ code into 
code, ready for compilation. i 
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Preprocessor 
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^ Code > 



Machine 
Code 



Following the lead of C++, various traditional languages have been adapted 
for OO programming. Object PASCAL evolved from PASCAL, CLOS from 
LISP, Objective-C from C, and Object COBOL from COBOL. This evolution of 
languages is shown in Fig. 17.6. 

Traditional compilers can be used with hybrid languages by means of a prt^ 
processor 



OO 
Language 



Preprocessor 



^ Traditional. 
Language 



Compiler 



Machine. 
Code 



An advantage of adding OO capability to an existing language is that the 
users of that language learn an extension of what they already "know, rather than a 
completely new language. ■ 

- This evolutionary learning path, however; has a severe disadvantage. OQ 
thinkmgis very different from traditional structured thinking, and hybrid lan- 
guages encourage programmers to think in the way they are used to thinkingfllic 
programmers then tend to do traditional functional decomposition and use struc- 
ture charts rather than think in terms of classes and inheritance. They tend to 
think in terms of data-flow diagrams rather than event diagrams. Many C++ pro- 
grammers are using procedural code instead of OO methods, requests, and inheri- 
tance. They do not convert fully to the OO mindset m 

Often, the best way to make a C programmer learn to use C++ in an OO 
fashion is to make him program in Smalltalk for six months. The problem with 
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Figure 17.6 The evolution of languages for OO programming/ 



this is that he might not want to leave Smalltalk, which often stimulates creativity 
better than C++. 

C++ has been referred to as a horseless carriage. The first automobiles' were^ 
called horseless carriages because they looked like traditional carriages with the* 
horse removed and a motor added. Because hybrid OO languages look like tradi- 
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tional languages, they tend to encourage traditional thinking — which is difficult 
to unlearn. 

For a new programmer, the pure OO languages are easier to learn than the 
hybrid languages, Smalltalk is fairly simple and uses English-like constructs. 
New programmers tend to learn it quickly. However, C++ is particularly diffi- 
cult to learn because it requires two stages of learning. The programmer must 
first learn C, which is a low-level language originally created for programming 
operating systems, and then the OO additions to C, which are unnecessarilv 
difficult. • * 

Pure OO languages, used well, have several advantages over traditional 
programming: 

• easier learning 

• reduction of complexity (a McCabe metric of 3 rather than 10) 

• easier debugging 

• reusable classes 

• reusability from inheritance 

• complexities hidden by encapsulation 

• easier to make changes 

• hence greater creativity 

This increased power and flexibility for the programmer has a price. Pure 
OO languages often give .machine performance lower than hybrid languages, 
^? Q ?++ is a fast, compact language, finely tuned for high-speed, execution. 
The performance disadvantage is steadily being overcome with better design of 
optimizing compilers forpure OO languages^ 



ENFORCEMENT 
OF DISCIPLINE 



OO advantages are achieved because of the discipline 
associated with encapsulation and inheritance. Hybrid 
languages make it only too easy to avoid this disci- * 
pline. Prognimmers often bypass encapsulation in favor of a quick solution. This 
can caii$e drugging problems arid make it much more difficult to make subse- 



quent modifications to programs, 
of the code " 



It generally lowers the Quality and reusability 



Enforcement of OO gfinciples, with their substantial benefits, is an argument for 
using pure, rather than hybrid, OO languages. Similarly, at a higher level, it is an 
argument for using pure, rather than hybrid CASE tools. . : - 
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i INTERPRETERS 
VERSUS 
COMPILERS 



An OO language should be interpretive, which 
enables the programmer to run the code as soon as he 
creates it As he makes minor changes, he can imme- 
diately run them without waiting for the entire pro- 
gram to be relinked. This immediate running of changes enables the programmer 
to be more creative— quickly catching errors and observing the effect of changes. 

Imagine a sculptor not being able to see changes he makes to his sculpture 
until some time later in the day when it is "compiled" This would drastically 
reduce the sculptor's ability to be creative. In a similar way, we want to increase 
the ability of the programmer to be creative. 

A problem with interpreters is that they generally give worse machine per- 
formance than compilers. Optimizing compilers take multiple passes through the 
[code linking it in such a way as to achieve the best machine performance. How- 
[evet; languages using conventional compilers limit creativity, because each small 
[change requires relinking the whole program which takes from minutes to hours. 

Some O O languages s otve-tiusrprc^te m b y meansrof-^dynamic-compilen- 

Am is compiles a method (rather than compiling entire programs) whenever the 
imethod is encountered It keeps a pool of recently compiled methods in the mam 
memory to avoid recompilation whenever possible. This is a compromise 
^between traditional interpreters and compilers. The programmer can run changes 
Iwhen he makes them, and the efiBdency of runtime execution is high (Rg. 17.7). 
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Figure 17.7 To maximize programmer creativity, the programmer should be 
able to execute changes as soon as he makes them— with no delay between pro- 
gramming time and runtime. This is achieved by using an interpreter or dynam- 
ic compiler. 
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To allow the programmer to interact immediately with evolving code and to 
achieve the best machine performance, a language should have both an into 
preter for use during development and a compiler for use when the program u 
run (Fig. 17.8). 
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Figure 17.8 To maximize programmer productivity and machine perfor- 
mance, an OO language may have both an interpreter and an optimizing 
compiler. 



POINTERS 00 software uses many pointers. Each object is 

linked to its class with a pointer mechanism. Finding 
the right method in a class hierarchy needs pointers. When an object sends 
requests to other objects, pointers are used, : - - - - : ~ 

The fields in an object may contain pointers to other objects. In order to 
..- point to an object,* each object must be uniquely identifiable. 

Figure 17.9 shows two Musical Composition objects. Each contains i 
pointer to a Composer object, Beethoven in this case. The Musical Composite 
objects have attributes to which it also points, such as opus number '-and compost? 
tion name; the Composer object has attributes, such as composer name, year 
birth, and year of death. 

An OO language must provide a good pointer rnechanism. This employs 
unique object identifiers (IDs); the object IDs should be automatically assigned 
and maintained by the system; the system ensures that they arc unique. The 
pointer links arc built by the software either at compilation time or runtime. 

Object IDs have important advantages. They are small and require minimal 
storage. They arc much smaller than human-readable names or references based 
on content The pointer to the object can be followed quickly. The object can be 
located with tables, regardless of where it is stored. The ID is independent of the 
object content Every variable in the object can be changed and the pointer still 
points to the correct object 
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Musical Composition 




Figure 17.9 Objects arc automatically allocated unique identifiers (IDs) so 
that points can link to them. ; . _ . . " 



jJSTATIC VERSUS Pointers arc essential to OO operation. The process of 
; DYNAMIC BINDING detennining the item that is pointed to is called bind- 
ing. Binding identifies the receiver of a request and 
. can be done when either the program is compiled or the program is run. The two 
| categories of binding cab be elaborated: 



Binding done when the program 
is compiled is called 

• compilctime binding, 

• early binding, or 

• static binding. 



Binding done when the program 
isrun.is called 

• runtime binding, 

• late binding, or 

• dynamic binding. 



276 



Tods 



Runtime, or dynamic, binding requires somewhat more overhead when the 
program runs, but it makes polymorphism possible. Because of this, some author- 
ities regard it as an essential component of 00 systems. 

An object may send a request to another object telling it to do something. 
The receiving object may have its own way of implementing the method request- 
ed It may use a method that did not exist at the time the program-was compiled. 
For example, it might print a chart, but the printer has been changed. It might 
compute the value of a portfolio with a method that has been modified. The 
request might go to an object in a distant machine, perhaps even in a different 
corporation. It may not be practical to recompile all the linkages between objects ' 
in different locations each time changes are made, so runtime (or dynamic) bind- [ 
ing is used. This gives a high level of flexibility. | 

Each object knows about its own way of executing a method, but different 
objects may execute that method in different ways. This is polymorphism. The 
request to Compute Invoice Total might be done differently in different locations 
because of particular discount schemes or sales, but a request of the same format 
is sent to all locations. The discounts and sales incentives change so often that it 
would not be practical to compile all linkages whenever a change occurs. So, 
runtime binding is used. 

Because overhead is associated with runtime binding, some languages auto- 
matically use compile-time (or static) binding unless runtime binding is specified. 
Some versions of C++ permit runtime binding only within one class hierarchy, 
because polymorphism can usually be confined to one class hierarchy. 

■,ji-.'- s ' *. , 
AVOIDANCE OF ^Procedural languages have statements (called CASE 
CASE STATEMENTS statement) that allow multiple options. For example. 

fFPR^ 



IF PRINTER IS TYPE-B DO 
"IF PRINTER ISTYPE-CDO 
IF PRINTER IFTYPE-D DO : . ~ / 



CASE statements such as these can usually be replaced by one statement 
PRINT. PRINT refers to a method that will be implemented differently in differ- 
ent objects depending on the type of printer used. A new type of printer can then 
be added and the same request remains valid. 

Sometimes CASE statements are lengthy because many possible options are 
specified, for example a different option for each type of customer. The CASE 
statement may be repeated in many programs. All options are hardcoded into the 
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program. To add a new option or delete an old one, a change has to be made 
wherever the CASE statement occurs* A large system may have thousands of 
CASE statements, hardcoding decisions into its programs. Changing the CASE 
options requires all the programs to be changed and tested In OO systems, the 
hardcoding of options can often be avoided Each object receiving a request has 
its own method of implementing that request New objects with different varia- 
tions on the theme can be added without changing a request or the code that 
sends it This flexible use of methods and polymorphism makes systems much 
easier to change. 

The more complex the system, and the more frequently changes are desired, 
the greater the advantage of not hardcoding options into the programs. The main- 
tenance of commercial systems would be much easier if they had been built with 
OO techniques. New objects or new options could be added easily when needed 
without changing existing objects. This increased flexibility will likely lead to a 
much higher rate of change in commercial systems. 



LANGUAGES AND 
ENVIRONMENTS 



Some OO languages have merely a compiler or inter- 
preter (or both), others have a language development 
environment, and yet others have a CASE environ- 
ment(discussed in the following chapter). These facilities are summarized in Fig. 
17.10. 
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Language 

• PureOO 

• Hybrid 

• High-level; easy to learn and use 
Interpreter/compiler Interpreter 



It Is desirable to have both 



• Interpreter 

• Compiler 

• Dynamic compiler 

Inheritance 

• Single 

• Multiple 

Binding 

-•-Statfc (axnpttetime) 

• Dynamic (compfletime) 

• Dynamic only within a class hierarchy 

Development Environment 

• Editor 

• Debugger 

• Browser 

• Windows 

CASE Environment 

• Analysis and modeling tools 

• Design tools 

• Prototyping tools 

• GUI builder 
Code generator 

• Visualization/animation tools 

• Repository 
Repository coordinator 

; Class Library 

• • For basic development 

• Appficatkxvindependent mechanisms (such as 
for LAN transaction processing) 

• For application areas 



Figure 17.10 Characteristics of OO languages and development environ- 
ments. 



278 



Chap. 17 



Object-Oriented Programming Languages 



279 



8. Khoshafian, Sctrag and Razmik Abnous, Object Orientation: Concepts, Lan- 
guages, Databases, User Interfaces, John Wiley & Sons, New York, 1990. 

9. Liskov, Barbara and John Guttag, Abstraction and Specification in Program 
Development, MTT Press, Cambridge, MA, 1986. 

10. Nygaard, Kristen and Ole-Johan Dahl, The Development of the Sim- 
ula Language," History of Programming Languages, ACM SIGPLAN 
History of Programming Languages Conference (Los Angeles), Richard L. 
Wexelblat ed., Academic Press, New York, 1981, pp. 439-493. 

11. Soley, Richard Mark, ed., Object Management Architecture Guide, Object 
Management Group, Document 90.17.1, November 1, 1990, Framingham, 
MA. 

12. Taylor, David A., Object-Oriented Technology: A Manager's Guide, Addi- 
son-Wesley, Reading, MA, 1992. 




OO-CASE TOOLS 



Object-oriented techniques and CASE technology fit naturally together. While 
the OO world initially emphasized 00 programming, the emphasis, today, 
should be on repository-based development with integrated CASE tools and a 
powerful code generator. 

00 is much more than a computer language or design technique: it is a way 
of thinking. CASE tools oriented to this way of thinking help the LS. profession- 
al, as well as the business person, engineer, or end user, to visualize automation 
in terms of OO models and specifications. 

; Some non-OO CASE tools have impressive code generators which gener- 
ate 100 percent of the code with no syntax errors. (There are often design errors; 
arbage-in-garbage-out applies to code generators) [3]. Code generators of 
equivalent quality ought to become the predominant way of creating OO appli- 
cations, along with a CASE repository of reusable classes. With OO-CASE tools^ 
the main emphasis of system building will be modeling and design^ rather than 
pO programming. 

Several OO analysis methods already exist in the data-processing industry, 
lowever; most are based on the structure of object-oriented programming lan- 
guages — rather than its fundamental principles. They begin by defining classes 
•tad superclasses and continue by specifying die data structure of the classes. Next, 
the operations associated with each class are identified. Since these loperations:: 
must connect in some way- their interfaces or request structures are defined. Final- 
ly* the methods for each operation are-tpecified Most methodologies do riot iden- 
tify events, triggers, rules, and state changes (as described in Part II). These are 
.important and should be an essential part of analysis and design methodologies. 



OO analysis methods should not be tied to OO languages and their support facilities. 
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Since technology for development is changing rapidly, we should analyze 
our systems independently of the programming tools used. Programming tech- 
niques should not drive the way we understand and communicate about our 
organizations. 



A VARIETY Various tools have been created to help make LS. 

OF TOOLS development faster, cheaper, and higher quality. Some 

tools are simple, others are complex. Simple tools 
should be reserved for simple systems, where a complex tool might slow down 
development Certain needs require only a report generator or a spreadsheet tool. 

In the early 1980s, fourth-generation languages (4GLs) were invented [2]. 
Some 4GLs use nonprocedural languages that offer ways to express what result is 
required-— not to achieve it SQL became a standard and provided a nonpro- 
cedural way to access relational databases. Other, more user-friendly, query lan- 
guages and report-generation languages-proliferated - . — 

Most fourth-generation languages were invented before object-oriented 
techniques were well understood Today, we need better end-user languages that 
incorporate OO techniques. Objects that have complex behavior may be shown 
on the screen as an icon. The end user can link many such icons together on a PC 
screen to build applications. This is done in some process-control software (e.g., 
from Gensym Inc.) and some decision-support software (e.g., from Metaphor 

inc.). ^ ; v.. 

Prototyping tools are important, enabling developers to build prototypes 
quickly and see how end users react to them: ProfotypingT^^g^ gave rise to 
iterative development iri wM^ ^ — - " 

CASE (Computer-Aided Systems Engineering) tools provided graphically- 
oriented ways of expressing pl^Models, and designs [4]. Code generators 
were created that could generate GOBOL^r-oth^r languages frtoin4urfi-Iever 
con$tructs.{lJ- - ~ — ~ ■ ~ - 

As CASE tools became more powerful, much of the design could be syn- 
thesized rather than built from scratch. The design tools were linked to a reposi- 
tory containing information usedih building^the design. The repoatory stored the' 
information involved in planning, analysis, design, and code generation; The 
repository contained ten^htes and reusable instructs th&Etould Wbbstomized 
for the system J>eing built It might contain specimen applications that could be 
modified Particularly important now, the repository should contain reusable OO 
classes, designed to be incorporated in applications. 

The tools really started to look powerful when these facilities were integrat- 
ed. CASE tools for planning, for data and process modeling, and for creating 
designs were integrated with code generators. Prototyping capability was linked 
into the design tools. Nonprocedural languages, including SQL and report gener- 
ators, were integrated into the CASE environment The term I-CASE describes 
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' integrated CASE products. Most important in I-CASE is the ability to generate 
code directly from the CASE design tooL An I-CASE repository contains design 
components in the form of reusable classes. 



PURE OO AND 
HYBRID CASE 

• non-OO 

• purcOO 

• hybrid 



Like programming languages, CASE tools can be 
divided into three categories: 




The CASE industry grew up in the late 1980s building non-00 tools. 
Because of this, OO enthusiasts have poured scorn on CASE tools [6] despite 
their clear success in facilitating faster development and maintenance* 

As OO techniques became better understood, some CASE vendors added 



OO concepts to their toolsets. Their repositories made available design objects, 



such as screens, dialogs, reports, tables, procedures, database-access mecha- 
nisms, transaction controls, and so on. Subtyping and inheritance made it possi- 
ble to use these design objects in a flexible way. The objects could be modified 
by users to incorporate into a particular application, as in Figs. 12.8 and 12.9. 

While design objects were used and helped with prototyping and code 
generation, the basic CASE diagrams generally remained the same. They sup- 
ported traditional structured techniques with functional decompositipn, struc- 
ture charts, and data-flow diagrams, rather than class Inejmcliies, subtyping, 
event diagrams, and the OO diagrams in general. The tools had a flavor of 00, 
but their basic core did not reflect the paradigm shift from structured techniques 
to OO techniques. 

More recently, pure OO-CASE tools evolved. These ^p^rtall. or most of 
the techniques described in Part II of this book and they generate code. Some of 
these evolved on one workstation, able to support one developer rather than 
teams of developers. 

Integrated OO-CASE tools are urgently needed. T^y enable development 
teams to share a repository, so that development can prbgr^s from ^ intelligent 
enterprise models to efficient system generation. ; 



CATEGORIES 
OF CASE TOOLS 



CASE tools can be categorized as I-CASE (supporting 
the whole lifecycle with a sing}p logically consistent 
repository) and fragment CASE (supporting only a 
portion of the lifecycle). Fragment CASE tools include frbnfcend tools (the analy- 
sis part of the lifecycle) and back-end tools (code generation). Some CASE tools 



284 



Tools 



Part III 



™5T ^ onnatlon peering (see Chapter 16) and help their users to build a 
model of the enterprise and analyze business areas. We thus have IE-CASE (for 
complete information engineering), I-CASE (integrated CASE that is not necw- 
y j5? na ? T ^^g)' md ^gment CASE. Any of these can be non- 
traditional but with an OO flavor, pure OO, or can support both traditional 
techniques and OO techniques. This categorization is shown inFig. 18 1 
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MnrSS? Figure 18^ repeats Fig. 5.1 and shows how we model 

MUUtLb v.- ^ design systems. The'capabilities in this figure 

«.n««^K .u s , i. ^fj^^d be: those of a CASE toolset. The methodology 
supported by the toolset should ensure that the modeling leads direcfly to design as 
autornatocaUy-as possible and that code is generated immediately fiorri iiie^deS. ~ 

lliem^l of ix5ahtyshodd.be as-meam^ 
corporate LS. we build a model, of (& enterprise. This should reflect the way the 
business people want to run me enterprise and facilitate discussion of how the 
enterpnsfrprocedures should.be changed. 

The early CASE tools modeled the enterprise with functional decomposi- 
fifn^ IaUonshl P diagrams, and matrices mapping entity types against 

functions. This modeling did not reflect how the enterprise operated and was not 
very meaningful to business people. OO modeling is more effective, because we 
identity events and the operations triggered by events. Event diagrams show 
streams of operations and allow us to reorganize the stream and redesign the busi- 
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The model 6hould reflect 
reality in a manner 
meaningful to end users. 



OO Model 
of Reality 



The design should have 
the same basic structure 
as the model. 




OO Design 



The code should be 
generated as automatically 
as possible from the design. 



Code 



Figure 182 CASE tools should enable us to model reality in a manner as 
insightful as possible to end users and to translate those models as automatical- 
ly as possible into the systems the users need. 

ness process. The value added by each o peration may be analyzed and operations 
of low value eliminated Various business rules state how the business should 
react to events, such as what to do about late payers, what factors have priority in 
shop-floor scheduling, and so on. These rules relate to business objects. We iden- 
tify the business objects, operations that change their states, and the rules that 
should govern these operations. 



h 
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The challenge of CASE tools today is modeling reality in a manner as insightful as 
possible to end users and translating the models as automatically as possible into 
the required systems. OO techniques help us to do that 



DESIGN SYNTHESIS The most powerful I-CASE tools allow as much 
AND CODE design as possible to be synthesized front high-level 

GENERATION constructs in the repository. The designer assembles 

the design and creates its detailed logic; Some design 
may be generated from high-level behavioral and structural statements such as 
state-transition diagrams, rules, decision trees, event diagrams, ihd object 
schemas[4]. ■ - : - ^ r - 

The design feeds a code genefator that creates 100 percent of the code with 
zero programming errors. The generated code should never have an ABEND. The 
testing process is geared more for catching the design errors than catching 
detailed coding bugs. 

The combination of design synthesis and code generation, shown in Fig. 
18.3, enables high-quality applications to be built quickly. A world of difference 
exists between the modern development lifecycle using the tools in Fig. 183 and 
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Reusable Classes 
Object-Structure Specifications 
Object-Behavior Specifications 
Rules 

Stereotype Applications 
Dialog Prototyping 



Manual Design 



Design Synthesis 



Code Generation 




Testing 



Production 
System 

Figure 18 J Design synthesis and code generation. 

the traditional building of systems with" filastic^templafes and line byline" 
COBOL coding. 

As far as possible, iheitekpi [should he_synth€^ized from 

• Object-structure diagrams and specifications . " *"_":.'/ Y._. 

• Object-behavior diagrams and specifications 

• Applicadon-independent classes 

• Classes for specific applications ^ '* z 

• Entire applications, designed for customization 

• Designs that can be customised 

• Declarative tables (e.g. t decision tables, event-condition-action tables) 

• A report generator 

• A screen painter 

• A dialog prototyping tool (GUI) 



CODE Pure OO-CASE tools need not necessarily use 00 

GENERATORS programming languages. They can generate code in 

languages such as COBOL or C — both of which arc 
efficient and portable and have highly efficient optimizing compilers. 

A problem with COBOL and C compilers is that they do not provide 
dynamic (runtime) binding which has the advantages described in the previ- 
ous chapter. Some OO-CASE tools generate C++ which provides dynamic 
binding as a requestable option but only for classes that belong to the same 
superclass. 

A principle of integrated CASE is that debugging does not involve changing 
instructions at the code level, but rather changing the design that drives the inter- 
preter or code generator. The interpreter or generator creates code with no syntax 
errors — this code can be tested like a black box and the source changed when 
necessary. This is particularly important if the tool generates a traditional lan- 
, guage, such as COBOL or C, at the code leveL 

We will refer to this immediate instantiation as instant CASK It helps the 
designerto be MgMy active, ^ 

tor; and modifying it as it evolves. Developers find instant CASE far more satis- 
fying than traditional CASE tools which require a long wait for code generation 
and compilation. With the latter, it takes too long to modify and improve what is 
being built 



INSTANT CASE Building systems with an interpreter is highly desir- ; 

able so that the developer can immediately run what 
he creates and repeatedly modify and evolve it As with pro^amming Taff^ 
guages, a CASE toolset should have both an interpreter and ail optimizmg 
compiler : ~ r ; 

With OO tools, as soon as an object type is described to the fool it can cre^ 
; ate tables that allow instances of the object to be created A description of its date 1 
can be built and tables of instances filled in. The designer can create sUbtyp^ 
composed-of hierarchies, and object-relationship diagrams and immediately fill 
in details of instances. Methods can be created and the behavior of the objects 
observed, tested, and adjusted. 

As soon as the designer describes object types to the XqoU the objects d/£ 
there and can be experimented with. This resembles a spreadsheet tool in which 
the designer can add columns end rows, specify computations, and immediately 
add values and ran the spreadsheet, generating and modifying charts. This ability 
of spreadsheet tools to create instant results should be emulated with OO-CASE. 
As soon as object types and methods are created, they can be observed in action. 
The designer can build up structures far more complex than spreadsheets in an 
interactive manner, can experiment with them, and test them; as a spreadsheet 
designer does. 
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PRECISION IN An article in Fortune [5] attempts to describe why 

DIAGRAMMING software is so difficult to create: 



Software is "pure thought stuff" so conceptual that designers cannot draw 
explicit, detailed diagrams and schematics — as creators of electronic circuits 
can — to guide programmers in their wort Consequently, routine communi- 
cation among programmers, managers and the ordinary people who use soft- 
ware is a chore in itself. 

This popular wisdom is wrong today, yfith the I-CASE tools, explicit, 
detailed diagrams and schematics are drawn, analogous to those used by electron- 
ic circuit designers, and code is generated from them. Much testing can be done 
at the diagram level. These diagrams are very effective for routine communica- 
tions among programmers, analysts, managers, and end users. Just as other engi- 
neering disciplines have precision represented in formal diagrams, so computer 
system developers also need formality and precision — in this case, enforced by 
-the computes 

Given appropriate diagramming techniques, describing complex activities 
and procedures is easier through diagrams than text A picture can be much better 
than a thousand words, because it is concise, precise, and clear. Computerized 
diagrams do not allow the sloppiness and woolly thinking common in textual 
specifications. Engineers of different types use formal diagrams that are precise 
in meaning — mechanical drawings, architectural drawings, circuit diagrams, 
microelectronics designs, and so on. The diagrams become the documentation for 
systems (along with the additional information collected in the repository when 
thefdiagrams are drawn), ^ ~ — 

A g6od CASE tool employs diSgranl riypes tfiarare precise and can be 
checks by computer. Largev complex -diagrams can:4)e handled by means of 
zooming; nesting, windowing, and other computer techniques. The computer 
quickly catches mors and in^Sfetepcfes evep. in very large sets of diagrams. 
Business, government, and the military need highly complex, integrated comput- 
er applications. The size and complexity of these applications require accurate 
diagramming using computers. ; - . > 

Thc^meaning represented by the diagram is more valuable than its graphic 
image. A^good CASE tool stores j^ ffie^^ form. 
The tool helps build up a design, a data 'model, or some other deliverable segment 
of the development process, so that it can be "validated and used in a subsequent 
development stage. - .- r^-- 



The evolution of OO-CASE technology represents an evolution-of application 
development from being a craft to being an engineering discipline. 
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DIAGRAMS FOR 
00 DEVELOPMENT 



For 00 analysis and development, CASE tools 
should enable their users to build the diagram types 
listed in Box 18.1. Many of these diagrams are the 
same as those for non-OO development: 



• Data structure diagrams (showing records, their fields, keys, and interrelations) 

• Action diagrams (showing the structure of procedural code) 

• Declarative tables (e.g. f decision tables or event-condition-action tables) 

• Tools for designing the graphic user interface 

• State-change diagrams (showing the state changes of an object) 

Some of the diagrams are essentially the same as those used in conventional 
data-centered development but with an OO flavor 

B0X18.1 



CASE tools for OO analysis and design should enable their users 
to build the following types of diagrams and generate code from them: 

For Object Structures: ' 

• Data-structure diagrams ~ 

• Object generalization diagrams ~ 

• Object-relationship diagrams ™ 

• Object composed-of diagrams 

Fbr Object Behavior • • : / : V: 

• Class-communication diagrams 

• Representations of methods 

— Action diagrams - • 

— Declarative tables ~ - 

• State-change diagrams 

< ..... . 

• Event diagrams 

• Rules, linked to event diagrams 

• Tools for designing the graphical user interface 



1 1 
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OBJECT-ORIENTED 
PROGRAMMING LANGUAGES 



|THE GENESIS OF The genesis of the technology now called object-ori- 
iQO TECHNOLOGY ented dates back to the early 1960s. It arose ftom the 
f need to describe and simulate a variety of phenomena 

i such as nerve networks, communications systems, traffic flow, production sys- 
|tems, administrative systems, and even social systems. In the spring of 1961, 
|Kristen Nygaard originated the ideas for a language that would serve the dual 
/purpose of system description and simulation programming. Together with Ole- 
fJohan Dahl, Nygaard developed the simulation language now known as Simula I. 
^The first Simula-based application package was implemented for the simulation 
of logic circuits. However, operations research applications were the most popu- 
u - usage. For example, in 1965 a large and complex job shop s&ulatibn was 
}grammed in less thin four weeks — with an execution efficiency at least four 
romeshigjierflian that of available technology [4,10]. ^ - 

e; ^ Simula was intended to be a system description and simulation program- 
piling language. However; its users quickly discovered that Simula also provided 
Spew and powerful facilities when used for purposes other than simulation, such 
m prototyping and application development In September 1965, the possibilities 
|6f a **new, improved Simula** as a general purpose language were being "planned; 
|By December 1966, the necessary foundation for the new, gen<^~ programming 
Slanguage, called Simula 67, was definfed. 



[SMALLTALK In the late 1960s, another development of OO tech- 

nology was under way, guided by research at the Uni- 
versity of Utah and by the central ideas of Simula. Alan Kay envisioned that by 
Stfae 1980s 
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Tools 



Part III 



[B]oth adults and children will be able to have as a personal possession a 
computer about the size of a notebook with the power to handle virtually all 
their information-related needs. . . . Ideally the personal computer will be 
designed in such a way that all ages and walks of life can mold and channel 
its power to their own needs [7]. x 

Early in the 1970s, Alan Kay went to Xerox and formed the Learning 
Research Group. Xerox was responsible for producing the interim model for the 
personal computer, called Dynabook. The group was engaged to produce the 
software, called Smalltalk. They quickly realized that one of the major design 
problems involved expressive communication — particularly when children were 
seriously considered as users. For this reason* the group invited some 250 chil- 
dren (aged six to fifteen) and 50 adults to try versions of Smalltalk and suggest 
ways of improving it In order to test the usability of Smalltalk, they started with 
simple situations that embodied a concept and gradually increased the complexity 
of the examples. A major goal o f Smalltalk was providing a single name (or sym- 
bol) for a complex collection of ideas. Later, these ideas could be invoked and 
manipulated through the name. They found that children by the age of six were 
able to do this. 

While the Dynabook project did not realize its goal, Smalltalk evolved into 
an important OO language. Alan Kay foresaw the need to characterize and com- 
municate application concepts in developing computer programs. Smalltalk pro- 
vides the means to write pro-ams in a style that brings our concepts to life: The 
term object-oriented originated during ^ie development of Smalltalk [J; 6j". Y 

THE EVOLUTION The kinds, or types, of data on which a program can 
FROM UNTYPED TO operate need to be organizedTnitially, ^nly on&data 
TYPED LANGUAGES type described the universe pf bit strings in a cbmput- 1 

• er memory — the data type Word. Words are bit 

strings of fixed size that can be used as units of information. 

The need for data types arises whenever data nuj$t be categorized for a par- 
ticular usage. As early as 1954, ^ FOftTRAN disfaguiAed betwera Integef and 
Roating-poirrt types of data. Later, Algol. 6Q incorporated data tyjpes i for Integer, 
Real, aiid Boolean. Still late^languages induded ^ditionsd datd types,- sucfras 
the Charades String, Bit, Byte, Array, Pointer, Record, File* and Procedure. 

A data type describes a certain kind of data^its representation and the set 
of valid operations that access and maintain that data. In this way, each data 
type is a known commodity, protected from unintended use, _For example, the 
data type Character describes the kind of data that is displayabte by a program* 
Furthermore, a set of operations is provided for creating, destroying, examin- 
ing, and manipulating Character data. Since arithmetic operations such as add 
and subtract are not defined for Character data, computational requests are not 
permitted [9]. 



USER-DEFINED Prior to the early 1970s, a programmer could reference 

TYPES (UDTs) only those data types built into a programming lan- 

guage compiler. As a result, even often-used types such 
as Month, Date, Time, Coefficient Tree, and Stack were not explicitly accessible. 
These ideas had to be implicidy embedded somewhere in the programmer's code. 
An additional limiting characteristic of built-in types was their definition by the 
way in which the information was physically stored They had little useful relation-/ 
ship to the real-world objects that the application was trying to implement 

Eventually, the computer industry felt pressured to provide programmers 
with a facility for expressing their own typing needs. The first languages to offer 
user-defined types (UDTi) were Pascal and Algol 68. In Pascal, for example, a 
programmer could write 

type month = (January, February, March, April, May, June, July, August, 
September, October, November, December); 



expression defines the UDT Month~as~te^ 
^developer could define relational operations to compare two given Month vari- 
[ ables for less than, equal to, and so on. Other operations could include computing 
^the preceding or succeeding month when supplied with a Month variable. 

The types of Pascal and the nodes of Algol 68 were an important step for- 
l ward. They permitted the programmer to go from manufacturer-imposed types to 
[user-imposed types. UDTs raised the expressive power of programming lan- 
Fguages. More importantly, they encouraged systems developers to translate the 
|ieal-world types of the system application into coded data types. 



[ABSTRACT DATA The abstract data type (APT) extends the notion of 
fPES (ADTs) the user-defined type (UDT) by adding encapsulation* 

The ADT contains the representation and the opera- 
ions of a data type. The encapsulation feature of the ADT not only hides the data 
type's implementation but provides a protective wall that shields its objects from 
[improper use. All interfacing occurs through named operations defined within 
the ADT. The operations, then, provide a well-defined means for accessing the 
objects of a data type. In short, ADTS give objects a public interface through its 
rmitted operations. However, the representations and executable code, or 
\method, for each operation are private. 

The ADT facility first appeared in Simula $7. Its implementation is called a 
class. Modula refers to its ADT implementation as a module, while Ada uses the 
word package. In all cases, the ADT provides a way for the systems developer to 
identify real-world data types and package them in a more convenient and com- 
pact form. In this way, ADTs can be defined for things such as Dates, Screen 
Panels, Customer Orders, and Part Requisitions. Once defined, the developer 
can address the ADTs directly in future operations. 
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Introduction 



The Deployment Editor enables you to map the business process applications and servers 
in your WFT workflow system to the physical architecture of your computer network. 
Business process applications are mapped to business process nodes, and servers are cre- 
ated as server nodes, or servers. This prepares your WFT workflow system for deploy- 
ment in the physical configuration of your network. The Deployment Editor then enables 
you to actually deploy your workflow system. Through the Deployment Editor, you can 
specify the communication protocols and addresses used for business pi^cess nodes and 
servers. You also specify the services that each server provides. You can also specify 
backups for servers. The Deployment Editor also enables you to develop a list of end 
users and their passwords for each business process node in the deployed system. 

See Chapter 7, Deploying a WFT Workflow System, in Developing a WFT Workflow System for more 
information about the concepts and process of deploying a workflow system. 

In this chapter, you will find how to: 
— Greate-business-process"nod*e^~and servers in your deployed workflow system. 

• Specify communication protocols and addresses for business process nodes and serv- 
ers. 

• Map the communication links between business process nodes and servers and the 
services provided over these links. ~* 

• Specify backup information for servers. - ■•■ "-* : -»-- ' 

• Develop lists of end users for the business process nodes jn your deployed workflow * 
system. , : r : : - - 



Prerequisites 



Before you use the Deployment Editor, you must create applicationsidr your WJFT w6fk-" 
flow system. ~ 
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portant terms 

The «. denned in T,b>e 8-, inCude som, ,* 
Table 8-1 . Important terms 



Term 



Definition 



Application 
Build 



Business process 
application 



Business process 

node 
Communication 

link 



Deployment 



Persistent storage 



Server 



7^^^^^ zero to 

many tasks. ... 
or server. 

An application that indudes ^^^^^^^^^ 

the job functions of a particular k.nd of employee. 
-A^ed-instance^La.b.u.iness process application in a WFT workflow 

system. . 

tion protocol it uses. 

ncTesto the physical architecture of the computer network. ^ 

A storage areaj'associated ^^"^^^^^^^^'^^^^nwte^ ap^i- 
stored copies of the messages J^ e J^_„s for each taslcwithin 
cation and the copies of any on P r 2^ , ^S^^ item traffic 

restarting or replacing a failed node. 
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Accessing the Deployment Editor 

To access the Deployment Editor, use either of the following methods: 
Method 1: 



vironment 



» Click the Deployment Editor button Ml in the WFT Development En 
main window. r 

Method 2: 

" °t°Tvf Ed "° r ^ me " U ta *" WFF Envifon- 

The Deployment Editor appears, as shown in Figure 8-1. 



Button for accessing the Deployment Editor 



Workspace 




Communication Protocols fist box 
Server Types buttons 
Tool box 



Figure 8-1- The Deployment Editor 

The Deployment Editor provides menus and tools for defining nodes and communication 
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About the Deployment Editor menus 



The Deployment Editor provides Edit, Actions,. and Show menus. The Y, Editors, Project. 
Options, and Help menus are common to all WFf Development Environment editors and 
are described in About lire status line on page 2-15 in Clmpter 2, Introduction to the WFT Develop- 

went Environment. 

The commands that appear on the Edit menu are listed in Table 8-2. 
Table 8-2. Commands provided on the Deployment Editor Ed/7 menu 



Command 



Description 



Enables you to manually change the size of the workspace. 
Automatically resizes the workspace to the smallest possible size that 

can contain all of the workspace elements. 
Enables you to specify when a copy of persistent storage for servers will 

be spooled. The copy can be copied to a secure storage device so 
that the s ystem can be recovered after a catastrophic failure, such as 

a hard disk crash. 



The commands that appear on the Actions menu anTlisted in Table 8-3. 
Table 8-3. Commands provided on the Deployment Editor Actions menu 



Set Workspace Size 
Auto Size Workspace 

Storage Backup 
Frequency 



Command 



Description 



Run All 
Clean Storage 



Runs all the business process nodes and servers in the workspace. 
Removes data from the persistent storage for all the business process 
nodes and servers in the workspace. ; 



The commands that appear on the Show menu are listed in Table 8-4. ; 
Table 8-4. Commands provided on the Deployment Editor S/iowmenu 



Command 

Application Name 

Host Name 

Storage Name 

Users 

Bitmap 



Description 



Displays in each business process node or server symbol the name of 

the application that runs in the business process node or server. 
Displays in each business process node or server symbol the name of 
the host computer on which the business process node or server will 
run. 

Displays in each business process node or server symbol the name of 
the business process node or server's persistent storage area. 

Displays in each business process node or server symbol the list of users 
that are defined for that business process node or server. 

Displays in each business process node or server symbol the bitmap 
selected for that business process node or server. 
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About the Deployment Editor tool box 

The Deployment Editor tools, buttons, text entry line, list box, and pop-up menus are 
described in the following sections. Figure 8-2 shows two examples of the Deployment 
Editor tool box. 



Grid button 



New Node 



Server 
Employee 



TJlerlc 

GEE 



Tools 

Grid size spin box 
Tool help text 



Communication Link 



Communication 
Protocols list box 



my 



Unix_Mai-l- 



Accountant 
Technician 



None 



Applications list box 



H Work Item 
.H Status :1 
-B~Error 



Error Server button 
Status Server button 
Work Item Server button 



Figure 8-2. Example Deployment Editor tool boxes 
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Deployment Editor tools 

The tools that appear in the tool box are listed in Table 8-5. In the tool box, the name of the 
currently selected tool is displayed in the tool help text area. 

Table 8-5. Tools provided in the Deployment Editor tool box 



Tool 



Select 



Description 



Enables you to select items in the workspace. 



Removes items from the workspace. 



Remove 



Edit Text In Place 



Edit Text 




New Node 




Enables you to edit communication link labels and some text information 

displayed in the business process node or server symbols where it 
- - appears Jn.the,W-Qrkspace. 



Communication Link 



Enables you to edit, in an edit window, communication link labels and 
some text information displayed in the business process node or server 
symbols in the workspace. 

Enables you to create a business process node or server in the work- 
space. Selecting this tool causes the Applications list box to appear in 
the tool box. 



Enables you to create a communication link between a business process 
node or server and a server in the workspace. Selecting this tool 
causes the Communication Protocols list boxand the Server Types but- 
tons to appear in the tool box. 
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Deployment Editor tool box buttons 

The grid button enables you to use the grid to help you place and align elements in the 
workspace. The grid is a ruled background on which you can snap elements to a particu- 
lar location. The grid button options are listed in Table 8-6. 

Table 8-6. Deployment Editor tool box grid button options 
Grid options Description 



gffip- j No Grid ~ Turns the grid off, whether it is visible or not. 

Grid On - Turns the grid on and makes it visible. When the grid is on and 
visible, the grid button displays a graphic representation of a grid. 

.&jt| Grid Invisible -Turns the grid on, but makes it invisible. When the grid is 
■•ffgPl on ' but invisible, the grid button displays a gray, shadow-like graphic 
representation of a grid. 



Deployment Editor tool box spin box 

The spin box that appears in the tool box is listed in Table 8-7. 
Table 8-7. Spin box provided in the Deployment Editor tool box 

Spin box Description 



Grid Size Enables you to set the size of the grid squares, in pixels. 

Using the up and down arrows, you can increase and decrease the grid size 
within the range of values fro m 2 to 400, inclusive. 

Deployment Editor Applications list box 

The Applications list box displays the names of all of the applications currently defined for 
your WFT workflow system. You deploy these applications as business process nodes or 
servers in your workflow system. This list box is oSly available when you select the New 
Node tool. 

Deployment Editor Communication Protocols list box 

The Communication Protocols list box displays the names of all of the communication proto- 
cols currently supported by your WFT workflow system, such as TCP/IP and UNIX mail 
You select one of the supported protocols when you define a communication link. This 
list box is only available when you select the Communication Link tool. 
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Deployment Editor Server Types buttons 

The Server Types buttons enable you to select the specific types of services that servers pro- 
vide. You select one or more of the types of services for each communication link you cre- 
ate. These buttons are only available when you select the Communication Link tool. The 
Server Types buttons are listed in Table 8-8. 

Table 8-8. Server Types buttons in the Deployment Editor 



Button Description 

Work Item Specifies that the server with which a given business process node commu- 

nicates via a given link provides work item services to that node. 

Status Specifies that the server with which a given business process node commu- 

nicates via a given link provides work item services to that node. 

Error Specifies that the server with which a given business process node or other 

server communicates via a given link provides error services to that busi- 
ness process node or server. 
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About the Deployment Editor workspace 

The Deployment Editor workspace, which is the large portion of the display to the right of 
the tool box, is the area in which you configure your workflow system's deployment You 
draw the various elements of your workflow system in this workspace, as though it were 
a large piece of drawing paper. The tool box provides controls for the grid in the work- 
space to help you align the representations of your workflow system elements. 

As you can do with many popular drawing programs, you can view this workspace dis- 
play as a window onto a larger virtual workspace. The Deployment Editor gives you a 
very large virtual workspace, one that you probably will not need to resize. Because the 
virtual workspace typically is larger than the display area in the window, scroll bars 
appear along the right side and the bottom of the workspace. 

If you choose the Print command from the T menu, the entire virtual workspace is 
printed, not just the currently displayed window onto the larger virtual workspace. 

Figure 8-3 shows an example Deployment Editor workspace. 





empO 


Applic; 


a Lion: Employee 


User: 


etnp 



\ 

TCP/IP 




clerfcO 
Application : Qertt 
U**r: cleric 



Business process node 
Business process node 

Communication link 



Server that has a 
backup node designated 
for it 



Figure 8-3. Example Deployment Editor workspace 



The symbol that represents a server can contain two graphic indixa^^^ 
left corner of the server's symbol indicates that the server provides status services to some 
or all of the business process nodes and servers that are connected-te k, -Similarly an Ein~ 
the upper left corner of the server's symbol indicates that the server provides error ser- 
vices to some or all of the business process^odes and servers that are connected to it 
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About the Deployment Editor pop-up menus 

The Deployment Editor provides pop-up menus for the following workspace display ele- 

• Business process nodes and servers 

• Communication links 

• Communication link line segment circles 

Pop-up menus appear when you click the appropriate workspace element using a non-left 
mouse button. The pop-up menus do not always contain all of the commands. The com- 
mands that are included at any given instant depend on the situation; commands that 
cannot be used in a given situation typically are not included in the pop-up menu at that 
time. The entire list of possible commands for the pop-up menus is described in the fol- 
lowing sections. 



Pop-up menu for business process nodes and servers 

The commands that appear on the pop-up menu for business process nodes and servers 
are listed in Table 8-9. * « 



IS' 6 8 ' 9 "„ Conf,mahds Provided on the Deployment Editor pop-up menu for business 
nodes and servers 



process 



Command 

Remove 



Description 



Edit Text In Place 



Edit Text 



Removes the selected business process node or server from the work- 7 " 
space. - 

"Enables you to edit some text information where it appears in the symbol 
for a selected business process node or server.' This comrnahd isohly 
available when you access the pop-up menu from-a text item that you 
can edit in the symbol for a business process node or server. - 
Enables you to edit in an edit window some text mformatiorvthat is dis^ - 
played in the symbol for a selected business process node pr server. 
This command is only available when you access the pop 7 up menu 
from a text item that you can edit in the symbol for a business process 
node or server. . ■ 

Enables you to specify the name of the host on which the selected 
business process node or server will run. 

Displays the node paths to the servers that provide services to a selected 
business process node or server. 

Enables you to edit the backup information for a selec ted server. This 
command is only available when you access the pop-up menu from a 
server. 



Set Host 

Show Server Paths 
Edit Server Backup 



Remove Server 
Backup 



Removes the backup information for a selected server. This command is 
only available when you access the pop-up menu from a server for 
which backup information has been specified. 
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Table 8-9. Commands provided on the Deployment Editor pop-up menu for business process 
nodes and servers (cont) 



Command 



Description 



Bitmap 



Storage Backup 
Directory 

Storage Settings 



Deployment Data 



Deploy 



Enables you to set the display of a bitmap within the-s/mbol for a selected 
business process node or server. This command provides the follow- 
ing additional commands: 

• Set Bitmap File - Enables you to select a bitmap to be displayed 
within the symbol for a selected business process node or server, 
in place of the default bitmap 

• Don't Use Bitmap File- Removes any bitmap from the symbol for 
a selected business process node or server. 

Enables you to specify the directory in which WFT places a copy of the 
selected server's data. 

Enables you to specify how to verify that data have been placed in persis- 
tent storage and how many items will be put into each persistent stor- 
age file. 

Enables you to edit the definition and specification information for a 
selected business process node or server. This command provides the 
following additional commands: 

• Node Name - Enables you to edit the name of a selected busi- 
ness process node or server. 

• Node User(s) - Enables you to edit the list of user names and 
associated passwords for a selected business process node. 

• Node Arguments - Enables you to edit the command line argu- 
ments to be passed to a selected business process ftode"<fr ; 
server at run time. . ... - . ■ 

• Node Storage Name- Enables you to edit the name" of the persist 
tent storage area for a selected business" process' hodd'br server. 

Enables you to prepare and deploy a selected business process node ' : or :Z 
server. This command provides the following additional commands: 

• Build- Builds the executable files for the "appHcatidh'thafwftPbe 7 - : ; 
deployed in a selected business process node. For a server" - 1 
builds the executable file for the server. ; \ , _ r ^ ;; ^ , . 

• Run - Runs the application for a selected business process node, 
if possible, according to the information specified for that business 
process node. Runs a selected server, if possible. 

• Debug- Runs the SNAP Debugger tor the node's application. 

• Clean Storage - Removes the persistent storage for a selected 
business process node or server. - 
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Pop-up menu for communication links 

The commands that appear on the pop-up menu for communication links are listed in 
Table 8-10. 

Table 8-10. Commands provided on the Deployment Editor pop-lip menu for communication 
links 



Command 



Description 



Remove 

Edit Text In Place 

Edit Text 

Split 

Show Label 

Set Protocol Values 



Set Backup Protocol 
Values 



Set Protocol 



Removes a selected communicatipn link from the workspace. 

Enables you to edit the label of a selected communication link where it 
appears. This command is only available when you access the pop-up 
menu from a communication link label. 

Enables you to edit the label of a selected communication link in an edit 
window. This command is only available when you access the pop-up 
menu from a communication link label. 

Splits a selected communication link into segments so that you can rear- 
range the link's graphic representation in the workspace. 

Displays the label associated with a selected communication link. 

Enables you to specify the communication protocol-specific values to be 
used by a selected communication link when it is used to communicate 
with a server. 

Enables you to specify the communication protocol-specific values to be 
used by a selected communication link when it is used to communicate 
with a servers backup. This command is only available when you 
access the pop-up menu from a communication link that is connected to 
a server for which a backup has been specified. 

Enables you to specify the cornrflunicatiori-protocbi>tb^*used by a 
selected communication link. This command provides the following 

additional Commands: ; /.;;;;;;,-,;;';.•.. - a ;r, ; 

• TCP/IP- Specifies that a selected communication link uses the 
TCP/IP communication protocol.- ~ . 

• Uiux Ma/7- Specifiesthat £ selected ,commupi^I^I^.uses the ~ 
UNIX mail communication protocol. " r r 

• None - Specifies that the communication protocol; for *a selected v * i 
communication link is currently undefined. ' .. : 



Pop-up menu for communication link line segment circles 

The command that appears on the pop-up menu for communication link line segment cir- 
cles is listed in Table 8-11. 

Table 8-11. Command provided on the Deployment Editor pop-up menu for communication 
link line segment circles 



Command 



Description 



Remove 



Removes a selected communication link line segment circle from the link 
and joins the two adjacent link line segments into a single communica- 
tion link line segment: 
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Working with business process nodes, servers, and 
communication links 

This section provides step-by-step information about using the Deployment Editor to ere 
ate either business process nodes where business process applications run or servers that 
provide services to other nodes, to create communication links between business process 
nodes and servers, and to specify deployment data. 



Creating business process nodes and servers 

To create a business process node or server, use either of the following methods: 
Method 1: 

1 . Select the New Node tool. 

The Applications list box appears in the tool box. 

2. Select from the Applications list box the business process application or type of server 
that you want to deploy in the business process node or server you are creating. 

3. Click the point in the workspace where you want the business process node or server 
to appear. 

Method 2: 

1. Select the New Node tool. 

The Applications list box appears in the tool box. 

2. Drag the business process application or server that you want to deploy from the 
Applications list box and drop it into th e workspace where you want the business pro- 

cess node or server to appear. 

A new business process node or server symbol that contains the name of the business pro- 
cess node or server appears in the workspace. The WFT names a business process node or 
server with its application name suffixed with a number. The suffix number represents 
the number of the instance of the particular business process node or server. The first 
instance is suffixed with 0 and the second with 1 and so on. For example, the first instance 
of a business process node where an employee (emp) application runs is named empO. 
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Creating communication links and specifying services 

You can draw communication links only from a business process node or server to a 
server but not from a server to a business process node. The business process node or 
server from which you draw the link typically originates communication over the link 
The server to which you draw the link typically communicates only in response to a busi- 
ness process node or another server that initiates communication. 

To create a communication link, perform the following steps: 

1 . Select the Communication Link tool. v 

The '.Ornvnunication Protocols list box and the Server Types buttons appear in the tool box. 
By default, all three Server Ty\ies buttons are selected, in anticipation that you want the 
server to provide all three types of services to the business process node or server that 
is connected to it by the communication link you are creating. 

2. Select from the Communication Protocols list box the type of communication protocol that 
you want to be used on the communication link you are creating. 

Click Server Types buttons, as appropriate, to specify the types of services the server 
provides over the communication link you are creating. 

Selecting and deselecting these buttons determines the types of services the server 
provides to the business process node or server that is connected to it by the commu- 
nication link. A server can provide any or all of these services. A business process 
node or server can be connected to as many as three servers, each of which provides a 
different one of the three types of services. , ! : . :1 

Click and hold the left mouse button on ffie syrnboi for the business process node or 
server from which you want the communication link.ro originate. ^ 

Drag the cursor to a position on the symbol for the-segfer with which you want the 
first business process node or server to communicate and release the mouse button. 



3. 



If the business process node or server at either end of the communication link requires 
a new set of communication protocol values (as determined by the WFT), a dialog box 
prompts you to enter the communication protocol values for the communication link 
you created. You can specify whether the protocol values you enter apply to the 
server or to the business process node that is connected to the server. Whenever pos- 
sible, default values are presented for the various data that you can enter. 

Enter the data for the protocol values or accept the default values and press OK. 

A new communication link symbol appears in the workspace. This symbol connects the 
originating business process node or server with its server. While the communication link 
can connect one server to another server, the originating server receives services in this 
case. 



6. 
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Removing workspace elements 

To remove workspace elements, use either of the following methods- 
Method 1: 

1 . Select the Remove tool. 

2. Click the element you want to remove. 

A dialog box prompts you to confirm the removal. 

3. Click OK. 
Method 2: 

1 . Choose Remove from the pop-up menu for the element you want to remove. 
A dialog box prompts you to confirm the removal. 

2. Click OK. 

The element is removed from the workspace. 

Specifying host names for business process nodes and servers 

To specify the name of the host computer on which a business process node or server -will 
run, perform the following steps: 

1 . Choose Set Host from the pop-up menu for a business processnode or server, ~ 

A dialog box prompts you for the name of the host computer. The default host name 
locattwst is supplied in the dialog box. - - 

2. Enter the host name or accept the default host name and press Enter or rlick OK./ 
The dialog box closes, and you are returned to the Deployment Editor. 
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Showing server paths for business process nodes and servers 

Ir°eps° W SerV6r P3thS 3 buS ' neSS prOCess node or server ' Perform the following 

1 . Choose Show Server Paths from the pop-up menu for a business process node or 
server. 

A dialog box displays the paths from the selected business process node or server to 
the server(s) that provide(s) the three types of services to the selected business process 
node or server. If you selected a server, and it supplies' services to itself, the paths con- 
tain the selected server's name. If none of the three types of services is being pro- 
v.ded to the selected business process node or server, the dialog box states that no 
path is specified. * 

2. Click OK. 

The dialog box closes, and you are returned to the Deployment Editor. 

Creating backup nodes for servers 

To create a backup node for a server, perform the following steps: 

1 . Choose Edit Server Backup from the pop-up menu for the server for which you want 
to designate a back up node. 

A dialog box displays default settings for a backup node. You can specify a liost " " 
name, persistent storage name, communication protocol, and communication proto- 
col values for the backup node. It is recommended that you specify a host name and a 
persistent storage name for the backup node that are different from those for. the main - 
server. yv_: . i"; \'_L". :'. \l*~';y IT-". 

2. Enter the data for the backup node and "Click -OK. _ _ i 



The dialog box closes, and a backup seivef symbol #p^afs in the workspace. The symbol 
for a backup server is a shadow behind the server that is backed up. 



Removing backup nodes for servers 

To remove a backup node for a server, perform the following steps: 

1 . Choose Remove Server Backup from the pop-up menu for the server whose backup 
node you want to remove. 

A dialog box prompts you to confirm the removal. 

2. Click OK, 

The dialog box closes, and the symbol for the backup server is removed from the work- 
space. 
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Editing names of business process nodes and servers 

When you create a business process node or server, the WFT generates a default name for 

!k u^" ? ! name ° f 3 bUSin6SS pr ° CeSS nodG ° r server if y° u do not w ™t to use 
the WFT default name. 

To edit the name of a business process node or server, use either of the following methods: 
Method 1: 

1 . Choose Deployment Data>Node Name from the pop-up menu for a business process 
node or server. 

A dialog box prompts you to edit the name of the selected business process node or 
server. 

2. Enter the new name and click OK. 
Method 2: 

1 - Choose either Edit Text In Place or Edit Text from the pop-up menu for the name of a 
business process node or server. 

2. Enter the new name directly into the symbol for the business process node or server in 
the workspace, or enter it into the edit window that appears, depending on wHich 
command you chose. 

The business process node or server name that is displayed in the workspace is changed 
to the new name. 6 

Adding business process node users dnd pdssW6rds T - : 

_____Only business process nodes can have users; servers do nothave users associated with 

them. Ib add user names and their associated passwords to a business process node per- 
form the following steps: f . . . ..... 

1 . Choose Deployment Data>Node User(s) from the pop-up menu for a business pro- 
cess node. .--Ts- :^ .... 

A dialog box displays the current list of user names for the selected business process 
node. ' 

2. Enter the values for the User Name and User Password as appropriate and click Add. 

The name of the user you added is displayed in the Node Users list box in the dialoe 
box. ° 
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3. Repeat step 2 for each user name you need to add and click OK. 

The dialog box closes, and you are returned to the Deployment Editor. 

Note that to edit the information for a specific user in the Node Users list box in the dialoe 
box, you must select a User Name from the list box, edit the values that appear in the User 
Name and User Password text entry lines in the dialog box, and then click OK. 

Removing business process node users and passwords 

Only business process nodes can have users; servers do not have users associated with 
them. To remove user names and their associated passwords from a business process 
node, perform the following steps: 

1 . Choose Deployment Data>Node User(s) from the pop-up menu for a business pro- 
cess node. r 

A dialog box displays the current list of user names for the selected business process 
node. " r 

2. Select from the Node Users list box in the dialog box the name of the user you want to 
remove. 

The values for User Name and User Password for the selected user name appear in the 
text entry lines in the dialog box. 

3. Click Remove. 

The name you chose is removed from the NodeXisers li£l>bxr~ : ~ : ' " " 

4. Repeat steps 2 and 3 for each user name you need to remove and dick OK. 
The dialog box closes, and you are returned to. the Deployment Editor. 



Specifying business process nocie or seryerjargumerits, - , , , ^ 

To specify command-line arguments that are passed to a business process node or server 
at run time, perform the following steps: 

1 . Choose Deployment Data>Node Arguments from the pop-up menu for a business 
process node or server. 

A dialog box prompts you to enter the command-line arguments that you want to 
pass to the business process node or server at run time. If you have already entered 
arguments, they appear in the text entry dialog box. 

2. Type the command-line arguments for the business process node or server and press 
Enter or click OK. v 

The dialog box closes, and you are returned to the Deployment Editor. 
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Specifying persistent storage for business process nodes and 
servers 

To specify persistent storage for a business process node or server, perform the following 

1 . Choose Deployment Data>Node Storage Name from the pop-up menu for a busi- 
ness process node or server. _ 

A dialog box prompts you to enter the name of the persistent storage area. 

2. Type the name of the persistent storage area and press Enter or click OK. 
The dialog box closes, and you are returned to the Deployment Editor. 

Showing business process node and server information 

You can display certain information abotft business process nodes and servers within their 
symbols in the workspace. This information includes the name of the application that 
runs m the business process node or server {Application Name), the name of the host ■ 



: com- 



puter on which the business process node or server runs (Host Name), the name of the per- 
sistent storage location associated with the business process node or server (Storage Name) - 
a hst of user names specified for a business process node (Users), and a bitmap image (Bit- 
map). You can display any subset or all of this information at the same time. 

To show information for business process nodes and ^rv^erform the following step: 
> S/lTmenu PliCati0n H ° St Name ' S ^^ N ^^^^^Jr6m^ ■ ■ 



The AppUcabon Name, Host Name, Storage Name, Users (for business process nodes), and Bitmap 
if specified) for each business process node and server are displayed in the symbols for 
the business process nodes and ser xers,_dependipg-on-^hich- € omm a nd^you chose 



Building business process nodes and servers 

You must build a business process node or server before you can run it. 

To build a business process node or server, perform the following step: 

^ Choose De P loy>BuiId from the pop-up menu for a business process node or server. 

The selected business process node or server is built. 
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Running a single business process node or server 

Note that you must build a business process node or server before you can run it. 

To run a single business process node or server from the Deployment Editor, perform the 
following step: r 

► Choose DepIoy>Run from the pop-up menu for a business process node or server. 

The WFT ivfetw messages window displays the results of the request to run the selected 
business process node or server. The process of running the business process node or 
server first verifies the business process node or server, builds the application that 
runs in it, and generates its deployment information. The Deployment Editor then 
runs the business process node or server. 



Running all business process nodes and servers 

Note that you must build all the business process nodes or servers before you can run 
them. J 

To run all the business process nodes and servers from the Deployment Editor, perform 
the following step; . . .. 

>- Choose Run All from the Actions menu. 

The WFT xvfenv messages window displays the. results of the.request,to run the business 
process nodes and servers. The process of running the business process nodes and 
servers first verifies the business process nodes and servers, builds the applications 

that run in them, and generates their deployment information. The Deployment Edi- 
tor then runs all the s^ers-and-business process nodes.-,— ' ; : - c - 
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Debugging a single business process node or server 

Note that you must build a business process node or server before you can debug it. 

To debug a single business process node or server from the Deployment Editor, perform 
the following step: 

v Choose Deploy>Debug from the pop-up menu for a business process node or server. 

The SNAP Debugger appears. You can debug your application as described in Chapter 10, 
Using the Debugger, in Using tlte SNAP Development Environment. 

Cleaning persistent storage for a single business process node or 
server 

Cleaning persistent storage for a business process node or server before running it pre- 
vents corruption of run-time data with any data lingering in persistent storage from a pre- 
vious execution of the business process node or server. 

To clean persistent storage for a single business process node or server, perform the fol- 
lowing step: 

> Choose Deploy>Clean Storage from the pop-up menu for a business process. node or 
server. 

Data are removed from the persistent storage area for the selected business process node 
or server. 

Cleaning persistent storage for all business process nodes and 
servers ' '""V- *. : " : " : " r - : 



Cleaning persistent storage for business process nodes ancLsecv&s before running them. v. 
prevents corruption of run-time data with any datailingering in persistent storagefrom a 
previous execution of the business process node&Gi[ sefVfefs, 

To clean persistent storage for all business process t\odes and servers, perform the follow- 
ing step: . 

> Choose Clean Storage from the Actions menu, 

Data are removed from persistent storage for all your business process nodes and servers. 
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Showing communication link labels 

You can display or hide the label associated with a communication link. The default label 
is the name of the communication protocol you specified for the communication link. 

To show a communication link label, perform the following step: 

> Choose Show Label from the pop-up menu for a communication link. 

The communication link label appears on the communication link in the workspace. If 
you have not edited the label for the selected communication link, the default label 
appears. Otherwise, the label appears on the communication link as you have edited it. 

Setting communication link protocol values 

To set the communication protocol values for a communication link, perform the follow- 
ing steps: 

1. Choose Set Protocol Values from the pop-up menu for a communication link. 

A dialog box prompts you to set the communication protocol values for the selected 
communication link. 

2. Enter the data for the protocol values and press OK. 

The dialog box closes, and you arp returned to the Deployment Editor. 

Setting communication link backup protocol values 

To set the communication protocol values for a communication link to a backed-up server, 
perform the following steps: ' 



1. Choose Set Backup Protocol Values from the p6*p-up menu for a cdhinmmtaffo^4m^^ - . 
that connects a business process node or server to arserver for Whfch a bd6kup ^rv^r " ~" 

is specified. 

A dialog box prompts you to set the communication protocol values forthe comrrlum- ^ : * 
cation link to the backup server. 

2. Enter the data for the protocol values and press OK. 

o b 
The dialog box closes, and you are returned to the E>epl6yrhent Editor. 
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Setting communication link protocols 

To set the communication protocol values for a communication link, perform the follow- 
ing steps: 

1 . Choose Set Protocol>(TCP/IP, UNIX Mail, or None) from the pop-up menu for a 
communication link. 

If a business process node or server at either end of the communication link requires a 
new set of communication protocol values (as determined by the WFT) a dialog box 
prompts you to enter those protocol values for the selected communication link You 
can specify whether the protocol values you enter apply to the server or to the busi- 
ness process node that is connected to the server. Whenever possible, default values 
are presented for the various data that you can enter. 

2. Enter the data for the protocol values or accept the default values and press OK. 
The dialog box closes, and you are returned to the Deployment Editor. 



Moving workspace elements 

You can move the following elements in the workspace: business process nodes servers 
communication links, and communication link labels. To move en element in the work- ' 
space, perform the following steps: 

- - "^ -- ■ . ■ 

1. Select the Select tool. •••• -- 

2. Click and hold the left mouse button on the element you want to move. 

3. Drag the element to a new location in the workspace, and release the mouse button. 

For communication links, dragging by the body of the symbol does nothing; dragging 

by the end-point selection handles moves the jjpk^wjthm the.restricaon noted-below 

For communication link labels, dragging the label moves it from one line segment in 
the selected communication link to another line segment in the same link. 

The element is moved to the new location in the workspace. The other elements are 
adjusted, as necessary, to reflect the moved element's new location. 

You can move the end points of communication links to new locations on their associated 
nodes, but you cannot move the links to different business process nodes or servers by 
dragging the link symbol from one business process node or server to another business 
process node or server. 

You can move communication link labels from one line segment in a link to another line 
segment in the same link. However, you cannot move communication link labels from 
one communication link to another link. 
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USING THE WORKFLOW SIMULATOR 



About this 
chapter 



This chapter describes the tools, menus, and other mechanisms provided by 
the Workflow Simulator for simulating and analyzing the operation of your work- 
flow system. 
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Introduction 



The Workflow Simulator enables you to create and run simulations of your workflow sys- 
tem design and deployment configurations. Using these simulations, you can evaluate 
alternative workflow system designs and deployment configurations, test "what if" sce- 
narios to explore design contingencies and variations, and observe your design's perfor- 
mance characteristics. 

See Cliapter 8, Simulating tlte Running of the WFT Workflow Systetn, in Developing a WFT Workflow 
System for more information about the concepts and process of building and running a 
workflow system simulation. 

In this chapter, you will find how to: 

• Build your workflow system for simulation by: 

V Defining simulation elements such as simulation nodes, tasks, and work item cre- 
ators and processors. ~ 

V Setting the timing of workflow system events. 

V Setting the probabilities of workflow system events. 

V Setting the number of instances for each simulation node. 

V Scheduling the activation and deactivation of simulation nodes over a given 
period of simulated time. 

• Simulate the deployment configurations and the operation of your workflow system 
design. 

• Perform "whatif" analyses of workflow system design and"deplby men t configuration 
variations. - ^ 

• Observe the performance of the simulatedoperation of your workflow system design 
and deployment configuration. ~ - 



Prerequisites 



Before you use the Workflow Simulator, youmust design ytfuf Wrkflow ^stem/using ; 
the Workflow Design Editor. See Chapter 3, Using the Workflow ^gnMtdf^n this document 
and Chapter 4, Designing a WFT Workflow System, in Developing a WFT Workflow System for more 
information about designing your workflow system. 
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Important terms 



u™^ fa i mC S ° me ° f the b3Sic terms y° u need to understand to 

use the Workflow Simulator. More detailed definitions and definitions of additional terms 
are included in Appendix A, Tlic Workflow Template Glossary, in Developing a WFT Workflow System. 

Table 9-1. Important terms 



Term 



Definition 



Animation 
Deployment 

Flow 
Junction 

Simulation 



Simulation 
node 



Subworkflow 
Task 

Work item 

Work item 
creator 

Work item 
processor 

Work item 
set 

Workflow 
system 



The graphic representation in the Workflow Simulator of the movement of work 
items through the workflow system during simulation. 

The process of defining the run-time configuration of a WFT workflow system by 
designating the relationships among the logical and physical elements of the 
system; the mapping of server and business process nodes to the physical 
architecture of the computer network. 

A possible route between tasks through which a work item can travel. A flow is 
associated with a single type of work item or a work item set. 

The point where one flow splits into multiple flows to form a copy flow or where 
multiple flows come together to form a compound flow. The junction for a 
compound flow can represent an And or an Or condition that is used to deter- 
mine how work items are processed. 

The modeling of the operation of a workflow system design and its deployment 
configuration. Simulation uses mathematical modeling and other tools to sim- 
ulate the movement and processing of work items among the tasks of the 
workflow system design. Simulation takes into Recount such variables as pro- 
cessing time delays, the probabilities of system events, and other factors 
Simulation only models the flowt>f work items-through-tasks; rather-than the 
task-specif ic processing -that is applied to the wprkltems in the tasks. * 
A partially configured node used by-the Workflow Simulator to simulate-deployed" 
nodes of your workflow system. A^imulatiori node is different from a node in 
the Deployment Editor; a simulation node is not dohTfgufed br speegfed 
deployment information as>ar£nodfcs in the Deployment "Editor, ^"sirnfflation' 
node is a collection of tasks, work item creators, and work item processors - - 



^tances^sinrafatiorrnodes fire genera^^uring a simulation. 

A graphic depiction of a subset of the overall business process described by a 1 
workflow design. i \. ' < 

The smallest significant unit of work activity wilhin a business process; a point in 1 

the workflow where work items 7 are created, : processed, or destroyed. 
The information processed by a task. 

A Workflow Simulator element that creates simulated work items in a task within 
a simulation node according to a specified rate and probability. 

A Workflow Simulator element that processes simulated work items in a task 
within a simulation node according to a specified speed. A work item proces- 
sor can also create work items as a result of the processing. 

A collection of one or more work items delivered as input to a task. 

A system that supports the automation of a subset or all of a business process 
A workflow system automates the flow of work items throughout an enterprise, 
enabling the monitoring and controlling of the business process. 
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Accessing the Workflow Simulator 

To access the Workflow Simulator, use either of the following methods: 
Method 1: 



Click the Workflow Simulator button 
main window. 



in the WFT Development Environment 



Method 2: 



>- Choose Workflow Simulator from the Editors menu in the WFT Development Envi- 
ronment main window. 

The Workflow Simulator appears, as shown in Figure 9-1. 



Button for accessing the 
Workflow Simulator 



Deployment View subwindow 




Simulation clock display area 
Workflows list box 
Tool box 



Design View subwindow 



Figure 9-1. The Workflow Simulator 

The Workflow Simulator provides subwindows, menus, and tools for simulating the 
deployment configuration and operation of your workflow system. 
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About the Workflow Simulator menus 



The commands that appear on the Edit menu are listed in TalSle 9-2. 
Table 9-2. Commands provided on the Workflow Simulator Edit menu 



Command 



Set Workspace Size 



Auto Size 
Workspace 



Description 

Enables you to set the sizes of the workspaces in the Deployment View or 
the Design Wewsubwindows. This command provides the following 
additional commands: 

• Deployment View- Enables you to manually change the size of the 
workspace in the Deploymeqt U/ewsubwindow. 

• Design View- Enables you to manually change the size of the 
workspace in the Design Wewsubwindow. 

Automatically resizes the workspaces in the Deployment View and Design 
Wewsubwindows to the smallest possible size that can contain all of the 
workspace display elements. 
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About the Workflow Simulator tool box 

The Workflow Simulator tools, buttons, text entry line, Workflow list box, and subwindc 
are described in the following sections. Figure 9-2 shows an example of the Workflow 
Simulator tool box. 



Grid button 




0 Show Deployment 
0 Show Design 
0 Animation 



Select 



Start Time: 

Thu Jun 15 14:49:46 1995 

End.Time: 
Thujun 22 14:49:46 1995 

Current Time: 
Wed Dec 31 19:00:00 1969 



B-p. Top Level 

t-^ Approve Funds 



Toots 

Grid size spin box 
Tool box buttons 
Toot help text 

Simulation clock display area 



Workffowsiist box' — 



Figure 9-2. Example Workflow Simulator tool box 
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Workflow Simulator tools 

The tools that appear in the tool box are listed in Table 9-3. In the tool box, the name of the 
currently selected tool is displayed in the tool help text area. 

Table 9-3. Tools provided in the Workflow Simulator tool box 



Tool 



Select 
Remove 

T 



Edit Text In 
Place 

jHj 

Edit Text 



Description 



Enables you to select items in the Deployment View and Design Wewsubwin- 
dows. 



Removes simulation nodes from the Deployment t/Zewsubwindow. 



Enables you to edit simulation node names where they appear in the Deploy- 
ment Wewsubwindow. 



Enables you to edit simulation node names in the Deployment Vfewsabwindow 
in an edit window. 



Enables you to create simulation nodes in the Deployment Wewsubwindow. 



New Node 
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Workflow Simulator tool box buttons 

The buttons that appear in the tool box are listed in Table 9-4. 
Table 9-4. Buttons provided in the Workflow Simulator tool box 



Button 



Command 



Grid options 



Show Deployment 
Show Design 
Animation 

Simulation control 



Enables you to use the -grid to help you place and align elements in the 
workspace. The grid is a ruled background on which you can snap ele- 
ments to a particular location. The grklbutton provides the following 
options: 

No Grid -Turns the grid off, whether it is visible or not. 

Grid On -Turns the grid on and makes it visible. When the 
grid is on and visible, the grid button displays a graphic 
representation of a grid. 

Grid Invisible -Turns the grid on, but makes it invisible. 
When the grid is on, but invisible, the grid button dis- 
plays a gray, shadow-like graphic representation of a 
grid. 

Displays the Deployment Vfewsubwindow. 
Displays the Design Vfewsubwindow. 

Displays the animated work items in the Design Wewsubwindow while the 
simulation is running. . _ . : 

Enable you to control the funnTng b'fthesimulation by starting, stoppihg; - 
resetting, and stepping the ^ simulation." The-following buttons enabled 
you to control the simulation:- -',= ■-; =• - - - . . . . : _ , r 

Resets the tribulation tS thd beginning of the simulation ~ 
period; dearsall-of the work item queues; and removes 
the status messages, queue workload bar charts, and 
animation, if any, displayed in the tagks-ih the Design - ' 
Wetvsubwindow;*- : : :r 



"StopsThe simulstioh at the "simulated -'cu^litli'rhig; leaves' 
all of the work item queues intact, and leaves all of the 
displayed informational You 
are not required4o:stop the^simulation befcwfe.you edit 
simulationynodes, but doing .fco is recommended/ 

Advances the simulation one step— that is, one simulation 
event; updates the queues and information displays; and 
updates the animation, if displayed. 

Runs the simulation from the current point to the end of the 
simulation period and continually updates the work item 
queues, information displays, and animation until the 
simulation ends. 
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Workflow Simulator tool box spin box 

The spin box that appears in the tool box is listed in Table 9-5. 
Table 9-5. Spin box provided in the Workflow Simulator tool box 

Spin box Description 



Grid Size Enables you to set the size of the grid squares, in pixels. 



Using the up and down arrows, you can increase and decrease the grid size 
within the range of values from 2 to 400, inclusive. 



Workflow Simulator tool box simulation clock display area 

The tool box simulation clock display area shows you the various times that are relevant 
to the simulation, including the Start Time, End Time, and the Current Time. The default val- 
ues for these times are as follows: 

• Start Time - The date and time when you first opened the Workflow Simulator in the 
current workflow system, which need not be the date and time of the current session. 

• End Time - Exactly one week (seven days) after the Start Time. 

• Current Time - None. ■ ■ ■ ■ 

You can change the Start Time and the End Time by clicking their displays to invoke the Time 
Editor dialog box. You cannot change the Current Time; it changes from None to the simu- 
lated time when the simulation is running. When you stop a running simulation, the Cur- 
rent Time displays the simulated time as of the moment you stopped the simulation. When 
you reset a simulation, the Current Time displays None. See Setting simulation start and end times 
on page 9-27. 

You set the various times in the Workflow Simulator according to your workflow system's 
view of real time. For instance, if yo u wan t to simulate the operation of your wor kflow 
system-over-the lu UI! « uf-areaTwork weekTthe you specifythe Start Time and En~dTime in 
terms of that real work week. You must enter the other various time values, including val- 
ues for work item processing times, work item creation rates, polling intervals, elapsed 
times, and more, in terms of real times as well. For instance, if a task takes one minute of 
CPU time on your computer network to process a work item, then you enter one minute 
for that work item's real processing time. Similarly, if that same work item is delayed for 
nine minutes due to printing time, phone calls, in-basket waiting time, or some other rea- 
son, then you enter ten minutes (one minute of CPU time plus nine minutes of delay time) 
for that work item's elapsed time. 
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The Workflow Simulator uses its internal clock and timers to track all of the simulation's 
time-based events. As the simulation progresses, the Workflow Simulator processes one 
event after another, advancing the simulation clocks accordingly. Note that the simulation 
is not based on a scaled-down version of real time. Instead, the simulation is based upon 
event processing. For example, if your workflow system has a task that creates a work 
item once every five minutes, the simulation processes the creation of a work item, 
advances the clock to the next time-based event, which is the next work item creation in 
this example, and processes the next work item creation. The simulation does not sit idle 
for a scaled-down version of the five minutes between work item creations. This concept 
applies to all of the time values you specify for the simulation; each value you specify 
results in a time-based event that the Workflow Simulator processes. 



Workflow Simulator tool box Workflows list box 

The Workflows list box displays the names of all of the workflows currently defined for 
your WFT workflow system. You use this list box to display the different workflows in 
the Design View subwindow. Names in this list box that are displayed with a plus sign (+) 
beside them are workflows or subworkflows that contain other subworkflows. You dou- 
ble-click these names to expand or collapse the listing of the subworkflows within these 
workflows. You click the name of a workflow or subworkflow to display the workflow's 
contents in the Design View subwindow. 
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About the Workflow Simulator Deployment View 
subwindow 

The Deployment View subwindow displays the configuration that is being simulated. 
Figure 9-3 shows an example of the Deployment View subwindow. 



Simulation Node 

Work item creator (green) Task 



eate Requisition 

REQUISITION (Approve Requisition, 
i r -^*Process Refusal 

i L "St REFUSAL (Check Inventory}, REFUSAL j 



Approve Requisition 
LJj REQUISITION {Create Requisitio 



—♦Check Budget 

L^j ORDER {Approve Requisition! 
^♦Update Records 
LJj ORDER (Check Budget), ORDER (Approp 
^♦Appropriate Funds 

ORDER {Check Budget) 



CI?;* 



J 0*check Inventory 

| L>j REQUISITION (Create Requisiti. 

!CD*Assemble Solution 

! L-JL (ORDER C REQUISITION) {Update 



Work item processor 
with outputs (yellow) 



Work item processor 
without outputs (red) 



Number of 
instances of 
the node 
being 
simulated 
over the 
number of 
instances of 
the node 
that can be 
simulated 



Figure 9-3. Example Workflow Simulator Deployment View subwindow 
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About the Deployment View subwindow pop-up menus 

The Deployment View subwindow provides pop-up menus for simulation nodes, tasks in 
the nodes, and work item creators and processors associated with the tasks. These pop-up 
menus appear when you click a simulation node, task, or work item creator or processor 
using a non-left mouse button. 



Pop-up menu for simulation nodes 

The commands that appear on the pop-up menu for simulation nodes are listed in 
Table 9-6. 

Table 9-6. Commands provided on the Workflow Simulator Deployment Wewsubwindow pop- 
up menu for simulation nodes M p 



Command 

Remove 

Edit Text In Place 



Edit Text 

Set Tasks 

Edit Polling Interval 

Set Bitmap File 

Do Not Use Bitmap 
Re 



Quantity 



Description 

Removes the selected simulation node from the workspace. 
Enables you to edit the name of the selected simulation node where it 

appears. This command is only available when you access the pop-up 

menu from a simulation node name. 

Enables you to edit the name of the selected simulation node in an edit 
window. This command is only available when you access the pop-up 
menu from a simulation node name. ~ - - - -- 

' - 'TajMgr- 

Enables you to specify the tasks that are inclSed in th^simulation noda 

Enables you to edit the polling interval for the selected simulation node. 
The default value is 5 Minutes. 

Enables you to select a bitmap to be displayed within the symbol that rep- 
resents the selected simulation node. 

Removes the bitmap from the selected simulation node and replaces it 
with the default bitmap. 

Enabl es you t o specify the number of instances of the selected s imulation 
node and the type of rate, flat or scheduled, at which the instances are 
to become active and inactive during the simulation time period. 

• Flat- Specifies that the simulation node instances are to become 
active at the beginning of the simulation period and remain active 
during the entire simulation period. A flat rate of 1 node instance - 
is the default value for Quantity. 

♦ Scheduled- Specifies that the simulation node instances are to 
become active and inactive according to a schedule that you ' 
specify. 
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Pop-up menu for tasks within simulation nodes 

The commands that appear on the pop-up menu for tasks within simulation nodes are 
listed in Table 9-7. 

Table 9-7. Commands provided on the Workflow Simulator Deployment View subwindow pop- 
up menu for tasks within simulation nodes 

Command Description 



New Creator Enables you to create a work item creator in the selected task. 

New Processor Enables you to create a work item processor in the selected task. 



Pop-up menu for work item creators and processors associated with tasks 

The commands that appear on the pop-up menu for work item creators and processors 
that are associated with tasks are listed in Table 9-8. 

Table 9-8. Commands provided on the Workflow Simulator Deployment View subwindow pop- 
up menu for work item creators and processors associated with tasks 



Command Description 

Edit Enables you to edit the selected work item creator or processor. 

Remove Removes the selected work item creator or processor from its~associated" ^ 



task. 
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About the Workflow Simulator Design View 
subwindow 

.^ ub : vindow dis P la y s the design of the workflow system that is being sim- 
ulated. Thus is the design you created using the Workflow Design Editor. This design rep- 
resents the running simulation. During the simulation, the following information is 
displayed in the Design View subwindow: 

• Bar charts depicting the work item queue load levels are displayed inside the task 

symbols. . 

• Symbols that represent the work items are shown moving along the flows, if anima- 
tion is turned on. 

• Messages that report the status of work item processing are displayed in the task sym- 

These bar charts, symbols, and messages are updated as the simulation progresses to 
show the loads in the queues, the movement of the work items, and the staLes of the 
tasks. Figure 9-4 shows an example of the Design View subwindow. 



Animated work item 




Work item processing 
status messages 



Subworkfiow 

Junction box in 
compound fiow 



Flow 



Task queue 
workload 
bar chart 



Figure 9-4. Example Workflow Simulator Design View subwindow 
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About the Design View subwindow pop-up menus 

The Design View subwindow provides pop-up menus for tasks, flows, and flow line seg- 
ment circles. These pop-up menus appear when you click a task, flow, or flow line seg- 
ment circle using a non-left mouse button. 

Pop-up menu for tasks 

The command that appears on the pop-up menu for tasks are listed in Table 9-9. 

Table 9-9. Command provided on the Workflow Simulator Design View subwindow pop-up 
menu for tasks 

Command Description 



Create Node Enables you to create a simulation node in the Deployment View subwin- 

dow in which you want the selected task to run, and enables you to 
specify the number of instances of the node you want to run during the 
simulation. This node and these instances are in addition to any other 
instances you specify in the Deployment View subwindow. 



Pop-up menu for flows 

The command that appears on the pop-up menu for flows is listed in Table 9-10." ^ :Vl} 

Table 9-10. Command provided on the Workflow Sfmulatbr Design View subwindow pop-up 
menu for flows . ; 

Command Description 

Split Flow Splits the selected flow into segments so that you can rearrange-the • - ; ; 

graphic representation in the workspace. 



Pop-up menu for flow line segment circles 

The command that appears on the pop-up menu for flow Iihe segment circles is listed in 
Table 9-11. 

Table 9-11. Command provided on the Workflow Simulator Design yiew subwindow pop-up 
menu for flow line segment circles 

Command Description 

Remove Removes the selected flow line segment circle from the flow and joins the 
two adjacent flow line segments into a single flow line segment. 
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Creating, editing, and running simulations 

This section provides step-by-step information about using the Workflow Simulator to 
construct and run a simulation of the operation and deployment configuration of your 
workflow system. 

Creating simulation nodes 

To create a simulation node in the Deployment View subwindow, use either of the foHowine 
methods: , 6 



Method 1: 



1 . Select the New Node toel. ^ - - . . ^ 

2. Click the point in the Deployment View subwindow where you want the simulation 
node to appear. 

A dialog box prompts you to select the tasks that you want to run in the simulation 
node you are creating. The list of tasks that is presented to you includes all of the 
tasks defined for your workflow system, regardless of the workflow or subworkflow 
in which they were defined. fc 

3. Select the tasks you want to run in the simulation .node you are creating and click OK. 

A new simulation node symbol that contams.s^to ~' 
appears in the Deployment View subwindow. - ^ 

Method 2: ** ■ : -"-^ ! ' : ' - ; ' v '-^ v : -' 

1. Choose Create Node from the pop-up menu .for, a task in the Design View subwindow. 

— ^^log^ox^romptB you to enter a value foTtl^riu^fe of h^tFnci^oFa^mub^ 
node in which you want the selected task to run.* ■ - ' '■ - 

2. Type a value for the number of instances of a simulation npdein ^Which you want the v 
selected task to run and press Enter or click OK. . . : : 

The dialog box disappears. A new simulation node symbol that contains the symbol 
for the selected task appears in the Deployment View subwindow The node is defined 
to have a flat quantity of instances; that is, the node's Quantity is the number you specie 
fied and the rate is Flat See Specifying quantities of simulation node instances ; on page 9-24 for 
more information. 



9- 16 Using the WFT Development Environment 



Creating, editing, ond running simulations 



Editing the assignment of tasks to simulation nodes 

To edit the list of tasks assigned to a simulation node in the Deployment View subwindow, 
perform the following steps: 

1. Choose Set Tasks from the pop-up menu for a simulation node. 

A dialog box prompts you to select the tasks that you want to run in the selected sim- 
ulation node. The list of tasks presented to you includes all of the tasks defined for 
your workflow system, regardless of the workflow or subworkflow in which they 
were defined. The tasks that are currently selected to run in the node are highlighted. 

2. Select the tasks you want to run in the selected simulation node and click OK. 

The selected simulation node symbol containing symbols for the tasks you selected 
appears in the Deployment View subwindow. - - 



Adding work item creators to tasks 

To add a work item creator to a task in a simulation node in the Deployment View subwin- 
dow, perform the following steps: 

1. Choose New Creator from the pop-up menu for a task in a simulation node. 

The Work Item Creation Editor appears! All bf the work items that flow from the 
selected task, according to the design of your workflow system; are listed in the Work 
Items display area. ; 'r- ; y;. nev.-;-.-^^^ - 



This editor enables you to specify the following work item creation characteristics: 

♦ The simulated time interval between work item creations,; including*.oth the 
duration of the interval and the interval time units. : : : 

— The probability of aj&oxkitemiite^ 

• Any coincidental work item creations that occur in conjunction witrTthe creation" 
of the selected work item; this is;nrce^ry^ 

later in the workflow system. See Spedf^ng. coined 

further details. .. ....... 



2. Enter a number for Interval, which is the simulated interval of time between successive 
creations of the selected work item. ^ + 

3. Choose a time unit from the pop-up menu for the Interval units display. 
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4. Enter a decimal number between zero and one, inclusive, for the Probability click at the 
appropriate location on the Probability scale indicator, or drag the Probability scale indi- 
cator to the appropriate location. 

5. Select the work items that you want to be created by the selected task. 

6. Specify the coincidental creations, if any, for this work item creator, as described in the 
next section in this chapter. 

7. Click OK. 

The Work Item Creation Editor closes, and a work item creator symbol appears beneath 
the symbol of the selected task in the simulation node. 



Specifying coincidental creations 

You use coincidental creations to simulate special cases in workflow systems where 
domain data, which cannot be simulated, would be the basis for decisions concerning the 
combining of work items in compound flows. Coincidental creations are important to 
consider for workflow systems that contain compound flows whose input work items are 
not descendants of the same work item. The following is a brief discussion of how coinci- 
dental creations work. 

The Workflow Simulator assigns an identifying number to every work item that is created 
during a simulation. If a task's processing of a work item results in the creation of another 
work item, the original work item's identifying numberis attached tome rievvly "created 
work item. In this sense, the newly created work item-inherits the original work item's 
identifying number to show that it is a child of the.original work item 

In the simulation of a compound flow, the work items that are combined into a work" item 
set must have matching identifying numbers; thaOis, they must be of fspring of the same 
onginal work item. Otherwise, the work items are not considered to match and cannot be 

combined. If two or more work items coming int o _a_cojnpound-flowlwere:Gn3at€d-by- — 

unrelated ancestor work items, their identtfyirignurnbers do not match. "' " - 

Coincidental creations provide a means for handling this situation. If you specify one 
work item to be a coincidental creation of another work iterh's creation, their idehtifvirie 
numbers will match, despite the fact that the Work items were not created from the same 
ancestor work item. 

When a work item creator generates a work item, that work item is assigned an identify- 
ing number. Also, if a coincidental creation is specified for that work item creator the 
Workflow Simulator forces the tasks that contain the coincidental work items to create the 
work items and assign to them the same identifying number. Note that you can specify a 
time delay for the creation of coincidental work items to simulate the probable time delays 
of your real workflow system. 
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You can define a work item creator for a particular work item and specify coincidental cre- 
ations for its coincidental work items. This models the case where one particular work 
item in the operating workflow system is always created before any of its coincidental 
work items. You can define work item creators that specify each other as coincidental cre- 
ations; this models the case where either work item is created first in the operating work- 
flow system. Note that work item creators that specify each other as coincidental 
creations do not result in an endless loop of one work item creating the other work item, 
and vice versa. 

To specify coincidental creations for a work item creator in a task in a simulation node, 
perform the following steps: 

1. Access the Work Item Creation Editor for a work item creator in which you want to 
specify coincidental creations, using either of the following methods: 

Method 1: 

>■ Choose New Creator from the pop-up menu for a task in a simulation node. 

The Work Item Creation Editor appears for a new work item creator. In addition 
to those tasSs you can perform with this editor, as described in Adding work item cre- 
ators to tasks on page 9-17, you can specify coincidental creations in the new work 
item creator. 

Method 2: 

>- Choose Edit from the pop-up menu for the given work item creator in a task in a 
• simulation node. _ _ 

The Work Item Creation Editor appears ; for the "selected^ r : : 

addition to those tasks you can perform with this editor, as described in Adding 
work item creators to tasks on page 9-1 7, you can specify coincident creations in tfce 
existing work item creator. " . :. :: :::: v... . ;.: .*.:: 

~2: Cftc^^ewWfheTig^ 

ation Editor. " ~- - ■ - ^ * : " 1 ; : r ; "-'*'" ;!r 

The Coincidental Creation Editor appearsl V All of the simulation /nodes in the deploy- . " 
ment View subwindow are listed in the Nodes display area. 

3. Enter a number for the Delay Time. ' 

The Delay Time is the period of time between the creation of the work item you are edit- 
ing and the creation of the coincidental work item. 



4. Choose a time unit from the pop-up menu for the Delay Time units display. 

5. Select the simulation node that contains the task that contains the work item you want 
to be created coincidentally. 

The names of the tasks that run in the selected simulation node appear in the Tasks dis- 
play area. 
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6. Select the task that contains the work item you want to be created coincidentally. 

The names of all of the work items that flow from the selected task, according to the 
design of your workflow system, are listed in the Work Items display area. 

7. Select the work item that you want to be created coincidentally 

8. Click OK. 

The Coincidental Creation Editor disappears, and the work item appears in the Coinci- 
dental Creations display area in the Work Item Creation Editor. 

9. Repeat steps 2 through 8 for each remaining coincidental work item creation for the 
work item creator that you are editing. 

10. Click OK. 

The Work Item Creation Editor disappears. 



Adding work item processors to tasks 

To add a work item processor to a task in a simulation node in the Deployment View subwin- 
dow, perform the following steps: 

1. Choose New Processor from the pop-up menu for a task in a simulation node. 

The Work Item Processing Editor appear^': All of the work Items that flow into the 
selected task, according to your workflow design, are listed in .the Input Flaws display,, 



area 



This editor also enables you to set a numfeer of other work item prbcesspr characteris 
tics. You can set the amount of time the; task takes to process the work item, both in 
i£a]imie_aiKUn^psed-tir^ 

the amount of dedicated CPU time that WdxM fe§ f^utf^ to pr6cess"the worlc item, 
while elapsed time is equivalent to real time plus any ^ 

or end-user-related delaying time that is^involved in tfe^bc^mg ;^t^ wp^era: 1 " 
You can specify any output work item creations ^ result fTprri the processing pf^&f 
selected work item, including the forwarding of the injpiit flbvv work item to its next 
task. In specifying these output work item creations, you can set the work item to be 
created and its probability of creation. 

If you specify more than one output work item creation, you can specify that they are 
or are not exclusive. If you specify that output work item creations are exclusive, then 
at most one of the output work items is created when the selected work item is pro- 
cessed; the probabilities of all of the output work item creations are summed and are 
normalized to 100%. If you specify that output work item creations are not exclusive, 
each output work item creation is evaluated separately, according to its respective 
probability, to determine if the output work item is created when the selected work 
item's processing is complete. 



9-20 Using the WFT Development Environment 



Creating, editing, and running simulations 



2. Select the input flows that you want to the selected task to process. 

3. Enter a number for Real Time, 

4. Choose a time unit from the pop-up menu for the Real Time units display. 

5. Enter a number for Elapsed Time. 

6. Choose a time unit from the pop-up menu for the Elapsed Time units display. 

7. Click the Output Exclusive check box to specify whether or not output work item cre- 
ations are exclusive. 

8. Specify the output work item creations for this work item processor, as described in 
Specifying output work item creations on page 9-21 . 

9. Click OK. 

The Work Item Processing Editor closes, and a work item processor symbol appears 
beneath the symbol of the selected task in the simulation node. If you specified output 
work item creations, the work item processor symbol that appears is yellow and has an 
arrow entering the top of the box and another arrow exiting the bottom of the box. If you 
did not specify any output work item creations, the work item processor symbol that 
appears is red and has an arrt>w entering-the top of the box, but no arrow exiting the bot- 
tom of the box. 



Specifying output work item creations - 

In the Workflow Design Editor, you defined all Of the ftovte Sy6ar"workflow system. 
Therefore, you defined what work items flow frx>m each task. Jn your workflow system 
design, you may have more than one type of work item flow from a particular task. The 
decision of which work item that task should create ^^d^d fe rriade by the processCtfg 

that occurs within the task In an operating workfl ow sysf^jaVany given moment or in" 

any given situation, a work item may or may not be created as a result of the processing 
that goes on in a task. During the simulation of the op^ratiori of ybiir workflow system, " 
output work items of a work item processor en^Bk-ybti%^Haftdieii^ situation by 
enabling you to specify how frequently a task creates a t work item as a result of processing 
some input work item. This ability enablesyou^speafy output work items in any way 
necessary to accurately reflect the nature of your workflow system. 
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To specify output work item creations for a work item processor in a task in a simulation 
node, perform the following steps: 

1 . Access the Work Item Processing Editor for a work item processor in which you want 
to specify output work items, using either of the following methods: 

Method 1: 

>- Choose New Processor from the pop-up menu for a task in a simulation node. 

The Work ItenvProcessing Editor appears for a new work item processor. In addi- 
tion to those tasks you can perform with this editor, as described in Adding work 
item processors to tasks on page 9-20, you can specify output work item creations in 
the new work item processor. 

Method 2: 

v Choose Edit from the pop-up menu for the given work item processor in a task in 
a simulation node. 

The Work Item Processing Editor appears for the selected work item processor. In 
addition to those tasks you can perform with this editor, as described in Adding 
work item processors to tasks on page 9-20, you can specify output work item creations 
in the existing work iterri processor. 

2. Click New at the right of the Output display area in the Work Item Processing Editor. 

The Work Item Processing Output Editor appears. The Ttames-of all "of the wdrleiterrl^ 
that flow from the selected task, according to your workflow design, are listed in the . 
Workltems display area. : : - z:: : ' .v/.. .:rv-; ~-:r:.".. 

3. Enter a decimal number between zero arid one^ mdusive^fe at the" 
appropriate location on the Probability scale indicator, or drag the Probability indicator to 
the appropriate location. : 



4. Select the work items you want to be created as output work items of the selected 
work item processor ' ~ "~ 



5. Click OK. 



The Work Item Processing Output Editor disappears. The output work item creation 
appears in the Output display area of the'Work Item Processing Editor. 

6. Repeat steps 2 through 5 for each remaining output work item for the work item pro- 
cessor that you are editing. 

7. Click OK. 

The Work Item Processing Editor disappears. 
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Editing work item creators and processors 

To edit a work item creator or processor, use either of the following methods: 
Method 1: 

1 >■ Choose Edit from the pop-up menu for a work item creator or processor in a task in a 
simulation node. 

Method 2: 

■m 

> Double-click the work item creator or processor you want to edit. 

Either the Work Item Creation Editor or the Work Item Processing Editor appears, 
depending on what you are editing. Edit the work item creator or processor, as necessary. 
See Adding work item creators to tasks on page 9-17 and Adding, work item processors to4asks on page 
9-20 for more information. 



Editing simulation node polling intervals 

When a task in a simulation node finishes processing a work item, it requests the next 
work item that is available to be processed. If such a work item is ready to be passed to 
the task, that work item is delivered to the task for processing. If such a work item is not 
ready, the task continues to make the request for. the 'next available work item at regular 
intervals of time. This repetitive requesting 7 is caOed polling. The polling interval is the ' 
time period between successive requests for the next work item. 

To edit a simulation node's polling inifercai/perfd^ " . : - 

1. Choose Edit Polling Interval frorrvthe pop-up menu fbr a stetllahOTrftodeT 1 iu; ; : ~ 

The Interval Editor appears, enabling, you to set both the numeric value and* the units 
for the polling interval '. 1__ - •"""* '"' : " : ~ v '--J-^i.— y? - : " 

2. Enter a number for the numeric value of the polling interval. _ 

3. Choose a time unit from the pop-up menu for the polling interval units display in the 
Interval Editor. 

4. Click OK. 
The Interval Editor closes. 
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Specifying quantities of simulation node instances 

The Quantity command on the pop-up menu that appears when you click a simulation 
node in the Deployment View subwindow enables you to specify the number of instances of 
the selected node that you want to be simulated and when those instances should become 
active and inactive during the simulation. The Quantity can be Flat or Sdieduled. 

The default for the Quantity command is Flat, with a default value of one node instance. 
This default means that only one instance of the selected simulation node will be simu- 
lated, and that the single instance will be active during the entire simulation period. You 
can specify that the Quantity be Flat, but that the simulation use more than one instance of 
the simulation node. 

Alternatively you can specify that the Quantity be Scheduled. That is, you can specify that 
the simulation use a specific number of instances (zero or more) of the simulation node, 
and that they become active and inactive according to a schedule that you specify This' 
ability enables the Workflow Simulator to model variable schedules that can more accu- 
rately reflect a real workflow system. 

If you specify a schedule for a selected simulation node, the Workflow Simulator begins 
simulating at the beginning of the schedule. As node instances become active and inac- 
tive, according to the schedule, the Workflow Simulator starts running and stops running 
those instances of the simulation node. If the simulation period ends before the end of the 
schedule is reached, the Workflow Simulator does not process the end of the schedule. If. 
the end of the schedule is reached before the end of the simulation period is reached,! the 
Workflow Simulator cycles back to the beginning of the schedule and continues process- 
ing. * , '" 



Note that the default length of your simulation node schedule is one week (seven days). 
You can increase or decrease the scheduled time period as you specify the schedule/ You 
can set the length of the scheduled time period as described in this section arid set the 
length of the simulation period as described in SmingtM &mutetimsmftaY^ 
scheduled time period of a simulation node and the overall simulation time period speci- 
fied by the Start Time and End Time need not be the same len g th^ r ITIILILLI 



Specifying a flat number of node instances 



To specify a simulation node's quantity as Flat, perform the following steps: 

1 . Choose Quantity>Flat from the pop-up menu for a simulation node. 

A dialog box prompts you to enter a value for the number of instances of the selected 
simulation node you want to run during the simulation. 

2. Type or click the numeric buttons to enter a value for the number of instances of the 
selected simulation node you want to run during the simulation and press Enter or 
click either OK or ENTER. 

The dialog box disappears. 
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To specify a simulation node's quantity as Sdieduled, perform the following steps* 

1 . Choose Quantity>Scheduled from the pop-up menu for a simulation node 

A Node Schedule dialog box appears, enabling you to specify a schedule for the number 
of instances of the selected simulation node that you want to run during the simula- 
tion and the schedule for when you want them to become active and inactive. 

The dialog box enables you to enter several items of information in addition to the 
actual schedule. You can enter the Maximum, which is the maximum number of 
instances of the selected node that can be active at any given time during the sched- 
ule. The Maximum defines the vertical axis of the schedule graph. 

You can enter the Variance, which is the maximum number of instances of the node that 
the actual number of instances may vary from the number of instances specified in the 
schedule. The actual variance is calculated by the Workflow Simulator during the 
simulation according to a Gaussian curve. 

The actual number of instances of the node during the simulation will always be 
within the range of zero to Maximum. However, within that range, the actual number 
of node instances at any point in the schedule will be the specified number of 
instances according to the schedule, plus or minus the actual Variance. The Variance fea- 
ture affords you more flexibility in modeling real workflow systems. 




You can enter both a numeric value and its time units for the Duration for the schedule. 
The Duration is the length of the scheduled period. You can enter bothTS numericvalue 
and its time units for the Interval within the schedule. The Interval is the time increment 
between points on the schedule graph where you can specify a number of instances of 
the node to be active. Typically, the Interval time unit is smaller than the Duration time 
unit. The defaults are one week for the DuratSm and one hour for the Interval. 

The Workflow Simulator reevaluates the active number of instances of the node at 
every interval — that is, at every^point in the sched\rt^where-you are allowed!^ spec- 
ify a new value. A new actual variance and a new actual number of nodes are calcu- 
lated at every interval. ^ f^:. 

The schedule graph in the dialog box displays the following items: 

• The scheduled period (Time) on the horizontal axis. 

• The range of possible instances of the node (Quantity) on the vertical axis. 

• The specified number of instances of the node as a solid, dark (black) line across 
the graph. 

• The possible range of variance in the number of instances of the node as lighter 
(red) lines above and below the line for the specified number of instances of the 
node. 
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2. Enter a number for Maximum. 

The schedule graph changes, if necessary, to reflect the new Maximum value. 

3. Enter a number for Variance. 

The schedule graph changes, if necessary, to reflect the new Variance value. 

4. Enter a number for Duration. 

The schedule graph changes- if necessary, to reflect the new Duration value. 

5. Choose a time unit from the pop-up menu for the Duration units display. 
The schedule graph changes, if necessary, to reflect the new Duration units. 

6. Enter a number for Interval. 

The schedule graph changes, if necessary, to reflect the new Interval value. 

7. Choose a time unit from the pop-up menu for the Interval units display. 
The schedule graph changes, if necessary, to reflect the new Interval units. 

8. Click and hold the left mouse button on a point along the dark line on the graph that 
represents the specified number of instances of the selected node. 

9. Drag the cursor up or down to the point on the graph ^ ^atcprre^ponds to the number 
of node instances that you want to run during that particular interval of the schedule, 
and release the mouse button. - ■ . ■ - - - - „. 

The point on the line representing the number of instances of the node during the 
selected interval is moved to the new value. 

— ifir-Repeat step^rasriecessary, forneax±i-intervaialoi\g the lilieiirtl^scrTeaule graph. 
11. Click OK. - . ' U 

The Node Schedule dialog box disappears. ' - 
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Setting simulation start and end times 

The default settings for Start Time and Bid Time result in a simulation period that covers 
seven days. You can set the Start Time and End Time to be whatever you require for your 
simulation. The Workflow Simulator begins simulating at the beginning of your node 
schedule and continues for as much of your schedule as can be processed between the 
Start Time and End Time. If your node schedule is longer than the simulation time period, 
the simulation does not process all of your node schedule. If your node schedule is 
shorter than the simulation time period, the simulation cycles through your node sched- 
ule until the simulation time period ends. 

To set the simulation Start Time and End Time, perform the following steps: 

1. Click the display of the Start Time in the simulation clock display area. 

The Time Editor appears, enabling you to set the'rhonth, date, hours, minutes, sec- 
onds, and year for the Start Time. 

Arrows are displayed both above and below the various elements of the Start Time dis- 
play in the Time Editor. Clicking the arrows above the elements increases the values 
of the elements. Similarly, clicking the arrows below the elements decreases the val- 
ues of the elements. Double-clicking the arrows sets the value to the nearest logical 
beginning or ending point for the specific unit; for example, double-clicking the arrow 
below the hours sets the hours to 00, while double-clicking the arrow above the hours 
sets the hours to 23. - .v; :-.^ . . ^ - • , - 



2. Click the arrows above and below the 1 various elements of the Start time, as necessary/ 
to set the appropriate date and time: — - : : . _ . - ■ . 

3. Click OK. 

The Time Editor closes, and the Start Time is displayed with the new values. 

4. Repeat steps 1 through 3 for the End Time in the simulaMort clock display area. 



5. Click OK. - r , - , : ;r; ^ s ;:.--.,vir 

The Time Editor closes, and the End Time is displayed with the new values, , A 
Note that you cannot set the Current Time for the simulation. 
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Stepping simulations 

Stepping a simulation means to advance the simulation one step at a time. A simulation 
step is considered to be one simulation event. For example, a simulation event might be a 
creation or processing event for a work item or task. 

To step a simulation, perform the following steps: 

1. Click the button in the tool box. 

2. Repeat step 1, as necessary. 

The simulation advances one step, or one event, at a time. The Current Time value in the 
simulation clock display area displays the current simulation time at the end of the simu- 
lation step. The numbers displayed in the upper right corners of the simulation node 
symbols in the Deployment View subwindow display the number of instances of that node 
that are active at the end of the step. Work item queue bar charts in the tasks displayed in 
the Design View subwindow display the work item workload level at the end of the step. 
Symbols representing work items appear on the flows between tasks in the Design View 
subwindow, if the animation is turned on. 

If you are using the Motif tool set, you can step a simulation by positioning the mouse cur- 
sor over the button and pressing the space bar; The result is exactly the same as for 
the above procedure. Holding the space bar down is the same as repeatedly clicking the 
button to step the simulation. If you are using-MS Window^or OS/2, youcan click the 
button, which places the focus of the windowing system oft the button, and then-press the 
space bar to achieve the same result. 



Running simulations 



Running a simulation means to advance the simulation continuously until either it ends 
or you stop it manually. „ 



To run a simulation, perform the following step: 



Click the jg^, button in the tool box. 



The simulation advances continuously until either you stop the simulation or the simula- 
tion time period expires. The Current Time value in the simulation clock display area dis- 
plays the current simulation time as the simulation runs. The numbers displayed in the 
upper right corners of the simulation node symbols in the Deployment View subwindow dis 
play the number of instances of that node that are active as the simulation runs. Work 
item queue bar charts in the tasks displayed in the Design View subwindow display the 
work item workload level as the simulation runs. Symbols representing work items 
appear on the flows between tasks in the Design View subwindow, if the animation is 
turned on. 
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Stopping simulations 

To stop a simulation while it is running, perform the following step: 
> Click the [ji] button in the tool box. 

The simulation stops running. The Current Time value in the simulation clock display area 
displays the simulation time as of when you stopped the simulation. The numbers dis- 
played in the upper right corners of the simulation node symbols in the Deployment View 
subwindow display the number of instances of that node that are active as of when you 
stopped the simulation. Work item queue bar charts in the tasked isplayed in the Design 
View subwindow display the work item workload level as of when you stopped the simu- 
lation. Symbols representing work items appear on the flows between tasks in the Design 
View subwindow, if the animation is turned on. 

Resetting simulations 

To reset a simulation to the beginning of its simulation time period, perform the following 
step: 

>■ Click the button in the tool box. st ^ ; * ' 

The simulation is reset. The Current Time value in the simulation clock display area dis- 
plays the default value None. The numbers displayed in the upper right corners of the 
simulation node symbols in the^Deploytnent View subwindowarej-eset. . Work item queue 
bar charts in the tasks displayed in the Design View subwindow disappear. Symbols repre- 
senting work items disappear frolri the' flows between tasks in the Design View subwindow, 
if the animation is turned on. 
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Moving workspace elements 

To move an element in either of the Workflow Simulator subwindows, perform the fol- 
lowing steps: 

1 . Select the Select tool. 

2. Click the workspace element you want to move. 

Handles appear on the workspace element to indicate that it is selected. 

3. Drag the element to the new location in the workspace and release the mouse button. 

For tasks and subworkflows in the Design V7m subwindow and for simulation nodes 
in the Deployment View subwindow, dragging by the body of the symbol moves the ele- 
ment; dragging by the selection handles resizes the element. For flows in the Design 
View subwindow, dragging by the body of the symbol does nothing; dragging by the 
end-point selection handles moves the element, within the restriction noted below. 

The element is moved to the new location in the workspace. The other elements are 
adjusted, as necessary, to reflect the moved element's new location. 

You can move the end points of flows to new locations on their associated tasks, but you 
cannot move the flows to new tasks by'dragging the flow symbols from one task to 
another task. 

Removing workspace elements from the Deployment View 
subwindow ^ , ^ w 

Because the Design View subwindow reflects the design of your workflow system. as speci- 
fied in the Workflow Design Editor, you cannot removeVle^nte.rrbiior acid elements to 
the Design View subwindow, with the single exception of the flow line segment circles that 
a* e only us e d for layo ut-purposes: ^ . — : — — — — — 

You can, however, add and remove elements in the Deployrnerit View subwindow Previous 
sections in this chapter describe how to add elements. You can remove simulation-nodes, 
tasks in simulation nodes, and work item creators and processors associated with the 
tasks. 
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Removing simulation nodes 



To remove a simulation node from the Deployment View subwindow, use either of the fol- 
lowing methods: 

Method 1: 

1 . Select the Remove tool. 

2. Click the simulation node you want to remove. 

A dialog box prompts you to confirm the removal. 

3. Click Yes. 
Method 2: 

1 . Choose Remove from the pop-up menu for the simulation node you want to remove. 
A dialog box prompts you to confirm the removal. 

2. Click Yes. 

The simulation node is removed from the Deployment View subwindow. 

Removing tasks from simulation nodes* . 



To remove a task from a simulation node in the Deployment View subwindow, perform the 
following steps: 

1 . Choose Set Tasks from the pop-up menu for the simulation node that contains the 
task you want to remove. 

A dialog box prompts you to select the tasks that you want to run in the selected sim- 
ulation node. The tasks that are already selected are highlighted in the dialog box. 

2. Select the task you want to remove from the simulation node. 
The selected task is deselected, and its highlighting is removed. 

3. Click OK. 

The task is removed from the simulation node in the Deployment View subwindow. 
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Removing work item creators and processors from tasks 

To remove a work item creator or processor from a task in a simulation node in the Deploy- 
ment View subwindow, perform the following step: 

> Choose Remove from the pop-up menu for the work item creator or processor you 
want to remove. 

The work item creator or processor is removed from the task in the simulation node in the 
Deployment View subwindow. 



Resizing task, subworkflow, and simulation node symbols 

To resize a task or subworkflow symbol in the Design View subwindow or a simulation 
node symbol in the Deployment View subwindow, perform the following steps: 

1. Select the Select tool. 

2. Click the task, subworkflow, or simulation node symbol you want to resize. 

Handles appear on the task, subworkflow, or simulation node symbol to indicate that 
it is selected. 

3. Drag any of the selection handles to resize the task, subworkflow, or simulation node 
symbol to the desired dimensions, and release the mouse button. 

The resized task, subworkflow, or simulation node symbol appears in the workspace. 
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THE WFT PROJECT STRUCTURE 



About this This appendix describes the WFT project file structure for a workflow system, 
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Introduction 



Introduction 



A number of files support the WFT Development Environment and your run-time work- 
flow system. At run time, the WFT creates additional files that hold various types of run- 
time data. These files are organized into hierarchical directories that correspond to the 
types of tasks and applications in your workflow system and to the nodes you create from 
those applications- A one-to-one correspondence exists between the directories and each 
type of task, application, and node in your workflow system. Figure A-l shows the direc- 
tory structure of a WFT workflow system. 



Project directory 



Task directories 



I Application directories 



C V-,' : 



Node directories 

■ L 



Persisten^stgr^^^dct#if 



Figure A-1. Project directory structures 

The main directory for a WFT workflow^ystem is called the project directory. All files 
and subdirectories created for your workflow system reside in the project direcFory or in 
one of its subdirectories. Figure A-l illustrates thebasic directory, striictureof the project 
directory. _ 



This appendix describes the structure and contents of the project directory and its subai- 
rectories. - ,. - - : ; :; ; 0 ■.- ;.-- !<ri . 
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About WFT Development Environment files 

You should not modify most of the files created by the WFT Development Environment. 
The exceptions are the class definition (cd) files such as wfsysjcd and routccd. These files 
contain your domain code. If you modify these files outside of the WFT Development 
Environment, the WFT will incorporate the changes you make when you invoke the WFT 
Development Environment. If you modify these files outside of the WFT Development 
Environment while you have the WFT running, the WFT cannot know that you are mak- 
ing changes. In this case, you must rebuild your base parsed class definition (pcd) file in 
the WFT Development Environment after you are finished editing the cd files. 



About the project directory 

The project directory is the main directory for your workflow system. It contains most of 
the WFT Development Environment files and your workflow system's main cd file, 
mfsys.cd. Table A-l describes the files that the WFT Development Environment creates in 
the project directory. 

Table A-1. Files created by the WFT Development Environment in the project directory 



File name 


Description 






aped.dat 


Application Editor information" ■ ^ - - 






ciasses.er 


Layout '"formation fcx tfe CJ.^.V ' 






deped.dat 


Deployment Editor information 






design.dat 


Workflow Design Editor runMimelhfbl'matibn :? v ' ~ r '~ " 






formdeidat 


Form Editor information 






route.cd 


Workflow Design Editor^routiRg "rules : - ! zz - ■ ; ? - 






sccd.dat 


Schema information for non-grellerated schemas" ----- - 






schmdef.dat 


Schema Editor information - T - - 






sctimreidat 


Work item and schema mapping information 1 " 






server.cd 


^ Abbreviated class definitions for inclusion in servers 






simulatn.log 


Workflow Simulator se'ssioh'infbrmation """"" 






tsked.dat 


Task Editor information . <» 






wded.dat 


Workflow Design Editor layout information ■ 






wfenv.dat 


Workflow project information 






wfproj.loc 


Local project information, including paths 






wfsys.cd 


Main class definition file 






wfsys.pcd 


Parsed main class definition file 






wfsys.sim 


Workflow Simulator information 
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About the task directories 

A task directory exists for each type of task you create using the WFT Development Envi- 
ronment. When you create a task, its task directory contains the files created by the WFT 
Development Environment. Table A-2 describes the files that the WFT Development 
Environment creates in each task directory. 

Table A-2. Files created by the WFT Development Environment in the task directories 

File name Description 

tdsk.dat Default task desk information 

formrel.dat Work item and form mapping information 

wftaed.dat List of files needed to edit the task 

Once you edit a task using the Task Editor, the standard data files that make up a SNAP 
application, such as macrodat and target Aat, are added to the directory. 



About the application directories 

An application directory exists for each application you create using the WFT Develop- 
ment Environment. When you create an application, its directory contains four files cre- 
ated by the WFT Development Environment. Table-A-3 describes the files that the WFT 
Development Environment creates in each application directory. 

Table A-3. Files created by the WFT Development Environment in the application directories 
File name Description 

formrel.dat Work item and form mapping information 

task.dat Task-related data file. This file exists when a task 
included wfthan-appltcatTonhas'beerredrted: 

tdsk.dat Default task desk information 

wftaed.dat List of files needed to edit the application 

Once you edit an application using the Application Editor, or edit any task grouped 
within the application, the standard files that make up a SNAP application are added to 
the directory. 
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About the business process node and server 
directories 

A business process node or server directory exists for each business process node or 
server you create and build using the WFT Development Environment. When you create 
a business process node or server, its directory contains three files created by the WFT 
Development Environment. Table A-4 describes the files that the WFT Development 
Environment creates. 

Table A-4. Files created by the WFT Development Environment in the business process node 
or server directories 

File name Description 

inst.dat Workflow deployment information 

userdat The business process node or server's user definitions 

worMlowdat Business process node or server data file information 



About the persistent storage locations 

A persistent storage location exists for each business process node or server you run. This, 
location is removed when you choose the Clean Storage.command in the Deployment Edi- 
tor. You should not edit or manipula te .in any way the contents of the persistent storage 
locations. " 
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+, see plus sign 



About command, editor Help menus 
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applications 7-14 

tasks 7-14 
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accessing the Application Editor 2-12 
deleting portions of class definition files 4-35 
editing 7-15 

relationship of directories to A-2, A-4 
removing 7-16 

Applications list box, Deployment Editor 8-8 

attachments 
adding in Glass Editor 4-36 
adding to attributes in Class Editor 4-40 
adding to constants in Class Editor 4-61 
adding to demons in Class Editor 4-55 
adding to functions in Class Editor 4-47 
adding to rules in Class Editor 4-51 
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Index 



attachments (cont.) 
definition 4-3 

deleting from attributes in Class Editor 4-40 
deleting from constants in Class Editor 4-61 
deleting from demons in Class Editor 4-55 
deleting from functions in Class Editor 4-47 
deleting from rules in Class Editor 4-51 
deleting in Class Editor 4-36 
editing names for constants in Class " 

Editor 4-61 
editing names for functions in Class 

Editor 4-47 
editing names for rules in Class Editor 4-51 
editing names in Class Editor 4-40 
editing text for constants in Class Editor 4-61 
editing text for functions in Class Editor 4-47 
editing text for rules in Class Editor 4-51 
editing text in Class Editor 4-40 

Attachments subwindow, Class Editor 
Attributes tab, pop-up menu description 4-40 
Class tab, pop-up menu description 4-36 
Constants tab, pop-up menu description 4-61 
Demons tab, pop-up menu description 4-55 
Functions tab, pop-up menu description 4-47 
Patterns tab, pop-up menu description 4h64- ■ 

Rides tab, pop-up menu description 4-51 

Types tab, pop-up menu description 

attribute display elements : . 

creating button display elements 6-64 
creating check button display elements 6-65 ; : = 
creating entry display elements 6-64 
creating icon display elements 6-66 - 
creating picture display elements 6-66 t:v re- 
creating radio button display elements 6-65 
— cr e ating su bfornrrdisplay-elei nents 6-6 8 — ~— ~t 
creating text display elements 6-64 
creating unspecified subform display - 

elements 6-69 
selecting subform display elements 6-68 

attribute value rules for routing 3-32 

attributes 
access, editing 4-73 

adding attachments in Class Editor 4-40 
applicability, editing 4-74 
constraint clauses, editing 4-40 
creating 4-39,4-71 
default values, editing 4-40 
definition 4-3 
definitions, moving 4-77 
deleting 4-73 

deleting attachments from in Class Editor 4-40 
deleting in Class Editor 4-38, 4-39 
editing 4-72 

editing constraint clauses in Class Editor 4-39 



attributes (cont.) 
editing default values in Class Editor 4-39 
editing names in Class Editor 4-38, 4-39 
editing names of attachments in Class 

Editor 4-40 
editing text of attachments in Class 

Editor 4-40 
editing types in Class Editor 4-39, 4-75 
finding refer&ices to and from using Class 

Editor 4-38 
local 

defining for functions in Class Editor 4-46 

deleting in Class Editor 4-46 

editing default values in Class Editor 4-46 

editing names in Class Editor 4-46 

editing types in Class Editor 4-46 

functions 

creating 4-80 

selecting types in Class Editor 4-46 
match, definition 3-3 
relation 
~ creating 4-19 

definition 4-4 

including in schemas by reference 5-7 
- -relocating 4-25 
—setting accesslevels in Class Editor 4-38, 4-39 
setting applicability in Class Editor 4^40 - 

setting applicability to instance in Class - - 

~ Editor 4-40 
■ setting- "applicability io-sMic in Class Crr J 

"Ecfitor 4-40 
^^settWig types in Glass Editor 4-40 < 
- - types, editing 4-75 - • ^ . 

At tributes list box, Form Editor 6-30 C . . , 
creatingimtton display elements 6-M v; i^r 
creating check button display elements '6^65" 7 
treating display elements using 6-30, 6-63 -.L a< 
creating entry display elements 6-64 H. .or - 
- creating icon display elements 6-66 
creating picture display elements 6-66 
creating radio button display elements 6-65- ' 
creating subform display elements 6-68 
creating text display elements 6-64 
creating unspecified subform display 

-elements 6-69- ^ 
selecting subform display elements 6-68 
Attributes tab, Class Editor 

pop-up menus description 4-38 
Auto Size Workspace command, Edit menu, 
Workflow Design Editor 
description 3-6 
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B 

backup nodes for servers 

creating 8-17 

removing 8-17 
Bitmap command, Form Editor 

icon button pop-up menu 6-41 
bitmaps 

working with in forms 6-72 ° 
Body subwindow, Class Editor 

Demons tab, description 4-54 

Functions tab, description 4-47 

Rules tab, description 4-50 
Box tool, Form Editor 6-26 
boxes 

creating in Form Editor 6-52 
Browse command, Classes list box pop-up menu, 
Object Model Editor 

description 4-11 
Browsing command, Options menu 

description 2-11 
building 

applications 7-14 

nodes 8-20 

servers 8-20 

tasks 6-14,7-14 
Button tool, Form Editor 6-27 — ; . 

buttons 

check 

creating 6-56 ..re- 
creating check button attribute display 

elements 6-65 "' 
description 2-23 • • -p: / :> " 

creating 6-56 

editor 



— description of (table)^^ - 

icon 

creating 6-57 - 
inform 

description 2-27 

kinds 2-27 
Object Model Editor 

using 4-5 
radio 

creating 6-56 

creating radio button attribute display 
elements 6-65 

description 2-24 
Server Types 8-9 
simulation 

description 9-8 
utility 

description of (table) 2-13 



By Hierarchy command, Classes menu, Object 
Model Editor 
description 4-7 
By Name command, Classes menu, Object Model 
Editor 
description 4-7 
By Source File command, Classes menu, Object 
Model Editor 
description 4-7 



callback functions 
associating wittt Form Editor display 

elements 6-69 
defining in Class Editor 4-42 
can 1-4 
cascade menus 
in WFT Development Environment 
description 2-23 
cd files 

developer-defined, adding 2-43 
names, changing in Class Editor 4-66 
predefined, adding 2-44 
removing 2-^J4 
routing, adding 2-43 
see also class definition files 
Centered command, Form Editor 
button pop-up menu 6-40 
icon button pop-up menu 6-41 
''^^f^yforkltem Type command, fl^s;" ~ 
pop-up menu, Workflow Design Editor 
: description 3-14 

using 3-29 - v: - --- 
Change Inform Callback command, Form" Editor 



- text entry-line pop-up menu 6-39 
Change Prompt command, Form Editor 7~. ""_ - 

text entry -fine pop-up menu 6-39 '_; 
Cltahge Style command, text and workspace pop- 
up menu, Workflo w Design Editor 
description 3-1 6 
Change Style command, text pop-up menu, 
- - * Workflow Design Editor 
7 using 3^33 ; ;: ' ' : ' :r 
Change Text command, Form Editor 

button pop-up menu 6-40,6-41 
Change Workflow command, subworkflows pop- 
up menu, Workflow Design Editor 
description 3-17 
using 3-34 

Change Workflow command, tasks pop-up menu, 
Workflow Design Editor 

description 3-13 

using 3-34 
Check Button tool, Form Editor 6-27 
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check buttons Class Editor (cont .) 

creating 6-56 Class tab 

creating check button attribute display description 4-34 

elements 6-65 pop-up menus 4-35 

description 2-23 classes 

Circle tool, Form Editor 6-26 . extensions 4-65 

circles, creating in Form Editor 6-52 inheritance 4-67 

Class Attributes subwindow, Class Editor names 4-65 

Attributes tab, pop-up menu description 4-39 column headings pop-up menu 4-32 

class continuations, specifying 4-35 description 4-32 

class definition files m Components menu 

definition 4-3 description 4-31 

deleting portions from applications 4-35 constants 

main, definition 4-3 adding 4-60 

specifying continuations 4-35 adding attachments 4-61 

specifying main 4-35 deleting 4-60 

Class Editor deleting attachments 4-61 

accessing 2-10,4-28 editing attachment names 4-61 

adding attachments 4-36 editing attachment text 4-61 

adding class definition files to editing names 4-60 

applications 4-35 editing values 4-61 

adding default objects 4-36 finding references to and from 4-60 

adding inheritance to classes 4-35 setting access levels 4-60 

attachments Constants tab 

creating 4-68 . description 4-5a 

deleting 4-70 Contents menu 

editing 4-69 , . .: , description 4-31 - - 

renaming 4-69 -- :: -Defined In subwindow pop-up menu 

attributes . - - description 4-35 

access, editing 4-73 , -deleting attachments 4-36 

adding attachments 4-40 , deleting. class definitions 4-35 

applicability, editing 4-74 deleting default objects 4-36 . ..v-: 

creating 4-39,4-71 • ; - deleting inheritance from classes 4-36 : 

deleting 4-38, 4-39, 4-73 deleting portions of class definition files 4-35 

do l c tin g-attaeh m c nts from-4-40 ... — , r ; demo i re , ; - : ..- rr~. — 

editing 4-72 , adding attachments 4-55 
editing constraint clauses 4-39 \ c j _ .dhefintng: 453 

editing default values 4-39 ; ; defining variables- 4^54 =„_.. . 

editing names 4-38, 4-39 . deleting 4-53 ; :„- " 

editing names of attachments 4-40 % . deleting attachments 4-55 

editing text of attachments 4-40 deleting variables 4-54 

editing types 4-39 editing attachment names 4-55 

finding references to and from 4-38 editing attachment text 4-55 

moving definitions 4-77 •* editing names 4-53 

setting access levels 4-38,4-39 editing names of referenced classes 4-54 

setting applicability 4-40 editing variable names 4-54 

setting applicability to instance 4-40 finding references to and from 4-53 

setting applicability to static 4-40 Demons tab, description 4-52 

setting types 4-40 displaying grid lines in subwindows 4-32 

Attributes tab Edit menu 

description 4-37 Add Extension command, using 4-30 

cd files, changing 4-66 Clear command, using 4-30 

Copy command, using 4-30 
Cut command, using 4-30 
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Class Editor 
Edit menu (cont.) 
description 4-30 

Find & Replace command, using 4-30 

Find command, using 4-30 

Find Next command, using 4-30 

Find Previous command, using 4-30 

Paste command, using 4-30 

Undo command, using 4-30 
editing names of attachments 4-36 
editing names of default objects 4-36 
editing names of inherited classes 4-35 
editing text of attachments 4-36 
error symbols 4-32 
functions 

adding attachments 4-47 

body, creating 4-81 

creating 4-42,4-78 

defining callback functions 4-42 

defining local attributes 4-46 

defining parameters 4-45 

deleting 4-42 

deleting attachments 4-47 

deleting local attributes 4-46 

deleting parameter names 4-45 

editing attachment names 4-47 

editing attachment text 4-47 

editing local attribute default values 4-46 

editing local attribute names 4-46 

editing local attribute types 4-46 - - 

editing nam^s 4-42 

editing parameter names 4-45 ^ 
editing parameter types 4-45 
finding references to and from ^-42 
local attributes, creating 4-80 ~ 




Class Editor (cont.) 
hiding columns 4-33 
introduction 4-28 

invoking fdr selected class 4-38 
menus, description 4-29 
patterns 
adding 4-63 

adding attachments 4-64 

deleting 4-63 

deleting attachments 4-64 

editing attachment names 4-64 

editing attachment text 4-64 

editing names 4-63 

editing values 4-64 

finding references to and from 4-63 

setting access levels 4-63 
Patterns tab, description 4-62 
replacing inheritance relationships 4-36 
rules 

adding attachments 4-51 
defining 4-49 
deleting 4-49 
deleting attachments 4-51 
editing attachment names 4-51 
editing attachment text 4-51 
editing-names 4-49 v *-^~. 
- finding references to and from 4-49 
' Rules tab, description 4-48 
- searching in columns 4-33 
-' sorting values in columns- 4-32, 4-33 T ~ 

specifying continuations 4-35 
••■sp^fyin^mairicia 4-35 - 

T menu 
r d^cript ion 4-29 

tabs ; r_T1 : ~ 
: rr "desariptioh 4-32 

sorting, multicolumn 4-33 - 
types 
adding 4-57 

adding attachments 4-58 

deleting 4-57 

deleting attachments 4-~58 : 

editing attachment names 4-58 

editing attachment text 4-58 

editing names 4-57 

editing types 4-58 

finding references to and from 4-57 

setting access levels 4-57 
Types tab, description 4-56 
variables 

defining 4-50 

deleting 4-50 

editing names 4-50 

editing names of referenced classes 4-50 



parameters, creating 4-79 

redefining inherited 4-42 

selecting local attribute types 4-46 

selecting parameter types 4-45 

setting access levels 4-44 

setting applicability 4-44 

setting kind 4-43 
to Exported 4-43 
to Exported External 4-43 
to Exported Native 4-43 
to External 4-43 
to Native 4-43 
to Remote 4-43 
to Shared 4-43 
to Shared External 4-43 
to Shared Native 4-43 

setting parameter kinds 4-45 

setting types 4-44 
Functions tab, description 4-41 
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class family, definition 4-3 
class inheritance, definition 4-3 
class symbols 
effects of settings on Show menu, Object Model 

Editor 4-13 
Object Model Editor 
graphic indicators 
description 4-13 
Class tab, Class Editor 
description 4-34 
pop-up menus 
description 4-35 
Class, Object, Attribute selectors 

see COA selectors 
classes 

adding inheritance relationships 4-35 
attachments 

creating 4-68 

deleting 4-70 

editing 4-69 

renaming 4-69 
attributes 

access, editing 4-73 

applicability, editing 4-74 

creating 4-71 ... .„ . 

definitions, moving 4-77 

deleting 4-73 

editing 4-72 

types, editing 4-75 : ." 
creating 4-18 _ ^ - - - 

definition 4-3 **- - 

deleting inheritance relationships 4-36 ■-■ ; 
editing 4-25,4-28 

extensions, creating 4-65 ... ; 

— f unction s, cr e a tin g 4 - 78 



inheritance, creating 4-67 
names, editing 4-65 

pop-up menu for, Object Model Editor " 
description 4-14 

predefined, displaying 4-18 

relation, definition 5-2 

replacing inheritance relationships 4-36 

symbols, resizing 4-25 
Classes command, Styles menu, Object Model 

Editor 4-8 
Classes list box, Object Model Editor 

description 4-11 
Classes menu, Object Model Editor 

description 4-7 
cleaning 

applications 7-14 

persistent storage directories A-5 

tasks 7-14 
cleaning persistent storage 8-22 



Clear command, Edit menu, Class Editor 4-30 
clearing dialog box information 2-28 
COA selectors 
in WFT Development Environment 

how to use 2-37 
what they contain 2-36 
COA selectors, description 2-36 
coincidental creations, specifying 9-18 
Collapse All command, Classes menu, Object 
Model Editor 
description 4-7 
Collapse command, Classes list box pop-up menu, 
Object Model Editor 
description 4-11 
Collapse command, Classes menu, Object Model 
Editor 
description 4-7 
column dividers 

moving 2-30 
column headings, Class Editor tabs 

pop-up menu 4-32 
columns 
hiding in Class Editor 4-33 
searching in Class Editor 4-33 
commands, status line display 2-15 , 
communication links . 
creating 8-15 - : : > : 

- setting backup protocol values 8-23 - • * 
: " isetting:protoco? values 8-23, 8-24 

showing labels 8-23 ... . mv.w:-. 

Specifying protocols for 8-15 ; .1 

; - "specifying services linked to 8-15 :::L>;!.\ 
- : communication protocols re i . 

setting backup values for links 8-23 : 

s^in^pvau^forlmks 8-23, 8=24 -ir^r,--.--* . 

'^^fying for communication liri^ 8-15 
Communication Protocols list box, Deployment- /- 
' : ! '-^ Editor 8-8 \ I -;:;;-;;-;:-: 

Components menu,. Glass Editor ; . 

description 4-31 
compound flows 
creating 349 - 
definition 3-3,3-19 
Condition subwindow, Class Editor 
Demons tab, description 4-54 
Rules tab, description 4-50 
constants 

adding attachments in Class Editor 4-61 
adding in Class Editor 4-60 
definition 4-4 

deleting attachments in Class Editor 4-61 
deleting in Class Editor 4-60 
editing attachment names in Class Editor 4-61 
editing attachment text in Class Editor 4-61 
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constants (cont.) 
editing names in Class Editor 4-60 
editing values in Class Editor 4-61 
finding references to and from using Class 

Editor 4-60 
setting access levels in Class Editor 4-60 
Constants subwindow, Class Editor 

Constants tab, pop-up menu description 4-60 
Constants tab, Class Editor 
pop-up menus 
description 4-6Q 
constraint clauses 

attribute, editing 4-39 
Contents menu, Class Editor 

description 4-31 
contexts 
changing contexts 
display elements in forms 6-75, 6-78 
forms 6-75,6-76 

Tool Box Context display in forms 6-77 

definition 3-3 
Copy command, Edit menu, Class Editor 

using 4-30 
copy flows 

creating 3-20 

definition 3-3,3-20 
-creating . ^ - 

attributes 4-71 

business process applications 7-11 v. 
classes 4-18 

attachments 4-68 

attributes 4-71 

extensions 4-65 

inheritance 4-67 
— Gommunieation-links-S-lS ; - ;,...,„ , 



creating 
form elements (cont.) 
filled circles 6-52 
filled polylines 6-55 
icon attribute display elements 6-66 
icon buttons 6-57 
lines 6-52 

picture attribute display elements 6-66 
pictures 6-57 
polylines 6-55 

radio button attribute display elements 6-65 
radio buttons 6-56 

subform attribute display elements 6-68 
text 6-57 

text attribute display elements 6-64 
text entry lines 6-58 
unspecified subfornt attribute display 
elements 6-69 
FORM graphics 6-51 
forms 6-15 
functions 4-78 
body 4-81 
local attributes 4-80 
parameters 4-79 
inheritance 4-20 ■ - 

- local attributes 4-80 -— - 
r nodes 8-14 - • ■ : 

-notes 3-23 ~- 
-parameters 4-79 • "~ ~- 
^projects 

in MS Windows 2-5 
in UNIX 2-4 
relation attributes 4-19 
f roles -3-22 ' - * 



schemas 5-TO 

scherrfeS for types of work items 3-20 
p servers 7-12, 8-14 
-Simulation nodes 9-16 
:;- sub workflows 3-25 

tasks 3-18 

types of work items 3-18 
workflows 3-25 
•creating rJackup nodes: for servers 8-17 
creating business 1 process nodes 8-14 
. creating projects 2-3 ;. 
creating servers 8-14 
creating WFT PATH objects 2-42 
Creators command, Show menu, Workflow 
Design Editor 
description 3-6 
cursors 
mouse (table) 2-21 



compound flows 3-19 
copy flows 3-20 : . ; t ue t . 

descriptive text 4-21 - : . .jV 

display elements using the Form Editor 

Attributes list box 6-30,6-63 ~ - 

dropdown lists 6-58 
entity-relationship diagrams 4-26 
flows 3-19 

flows between workflows 3-25 — 
form backgrounds 6-50 
form elements 
boxes 6-52 

button attribute display elements 6-64 
buttons 6-56 

check button attribute display elements 6-65 
check buttons 6-56 
circles 6-52 

entry attribute display elements 6-64 
filled boxes 6-52 
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custom routing 3-31 

attribute value rules 3-32 

custom rules 3-32 

external rules 3-31 

no rules 3-33 
Custom Routing command, flows pop-up menu) 
Workflow Design Editor 

Attribute Value Rule cascade entry, 
description 3-15 

commands that cascade from 3-15 

Custom Rule cascade entry, description 3-15 

description 3-15 

External Rule cascade entry, description 3-15 
None cascade entry, description 3-15 
Custom Routing>Attribute Value Rule command, 

flows pop-up menu, Workflow Design 

Editor 
using 3-32 

Custom Routing>Custom Rule command, flows 
pop-up menu, Workflow Design Editor 
using 3-32 

Custom Routing>External Rule command, flows 
pop-up menu, Workflow Design Editor 
using 3-31 

Custom Routing>None command, flows pop-up 
menu, Workflow Design Editor . 

using 3-33 . 
custom rules for routing 3-32 
Cut command, Edit menu, Class Edito^ - 

using 4-30 ;r~-]:rr. 

d ■ 

data 

saving WFT workflow system 2-38 
data files " , .. 



1 



demons 

adding attachments in Class Editor 4-55 
defining in Class Editor 4-53 
defining variables in Class Editor 4-54 
definition 4-4 

deleting attachments in Class Editor 4-55 
deleting in Class Editor 4-53 
deleting variables in Class Editor 4-54 
editing attachment names in Class Editor 4-55 
editing attachment text in Class Editor 4-55 
editing names in Class Editor 4-53 
editing names of referenced classes in Class 

Editor 4-54 
editing variable names in Class Editor 4-54 
finding references to and from using Class 
Editor 4-53 

Demons tab, Class Editor 
pop-up menus description 4-53 

deployment 
creating and editing 
accessing the Deployment Editor 2-12 

Deployment Editor 8-22 
accessing 2-10,8-4 

adding node users and passwords 8-18 
Applications list box 8-8 
building nodes and servers 8-20 
Communication Protocols list box 8-8 \- - 

creating, communication links 8-15 
creating nodes 8-14 
::. v. creating-servers 8-1 4 ~ . ; * 

debugging nodes and servers 8-22 , ; . ;^ 
- -introduction to 8-2: : : - : -V.~."-" ~ ' 

- ~ '.menus" 8-5 - v 

pop-up menus 8-11 
* purpose 2-12 r ~I 

- removing node or users and passwords 8-T9 
-removing workspace elements 8-16 ~:^-. ^v-a 

running nodes and servers 8-21 . , : 

: Server Types buttons 8-9 - .. „ *. 

showing node and server information 8-20 
specifying host names for nodes and 

servers 8-16 - ■ . , 

specifying node or sever arguments 8-19 

tool box 8-6 

tools 8-7 

workspace 8-10 
Deployment Editor command, Editors menu 

description 2-10 
Deployment View subwindow, Workflow 

Simulator 9-11 
descriptive text 

creating 4-21 

in Workflow Design Editor 
pop-up menu for, commands on (table) 3-16 



what they store 2-38 ,~ 
debugging 

nodes 8-22 ; :\ 

servers 8-22 
default objects 

adding in Class Editor 4-36 

deleting in Class Editor 4-36 

editing names in Class Editor 4-36 
Default Objects sub window, Class Editor 

Class tab, pop-up menu description 4-36 
default schemas 

when generated 3-22 
Defined In subwindow, Class Editor 

Class tab, pop-up menu description 4-35 

Class tab, when displayed 4-31 
deleting 

attributes 4-73 
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Design Hierarchy list box, Task Editor 6-10 
Design Hierarchy list box, Workflow Design 
Editor 

description 3-11 
Design subwindow, Workflow Simulator 9-14 
Destroyers command, Show menu, Workflow 
Design Editor 

description 3-7 
destroying the Messages window 2-32 
developer-defined cd files 

adding 2-43 
development process 

WFT 2-2 
Diagram menu, Object Model Editor 

description 4-6 
dialog boxes 

accessing edit windows from 2-28 

accessing the Object Set Editor from 2-28 

clearing 2-28 

entering unknown for the value 2-28 

getting more information 2-28 

in WFT Development Environment 

description 2-28 
using the Clear button 2-28 
using the Editor button 2-28 
using the Explain button 2-28 
, using the Table button 2-28 

using the Unknown button 2-28 
directories 
application directories 
files in A-4 

after editing using Application 
Editor A-4 
node directories A-5 
file s in A-5 



display elements 

in workflow design (cont.) 
that have pop-up menus 3-12 

list of focusable elements 6-84 
displaying 

predefined classes 4-18 
subworkflows 3-33 
workflows 3-33 
dividers 
movable 

moving 2-30 
pane and column 
description 2-30 
moving 2-30 
Do Not Use Bit?nap File command, subworkflows 
pop-up menu, Workflow Design Editor 
description 3-17 
Do Not Use Bitmap File command, tasks pop-up 
menu, Workflow Design Editor 
description 3-13 
drag and drop 

using in WFT Development Environment 2-26 
Dropdown List tool, Form Editor 6-27 
dropdown lists 

adding values to 6-58 
- - creating 6-58 -i^ 
Duplicate Object tool, Form Editor 6-26 " 




: - 7T E3ii CDTUe List command, Project menu 
7 description 2-10 

Edit Class command, classes pop-up menu, 
1 : ObjectM6del Editor 
description 4-14 



" Edit^mvrtAM;Roles menu, Workflow Design 
Editor 

- description 3-6 x '* 
Edit Ciirrefit "com'mand, Form Editor 

- icon button pop-up menu 6-41 

Edit Current command, Schemas menu, Workflow 
Design Editor 

description 3-7 
Edit Junction command, junction boxes pop-up 
menu; Workflow Design Editor 

description 3-14 

when a variable 3--T4 7 
Edit menu, Object Model Editor 

description 4-6 

using 4-12 
Edit menu, Workflow Design Editor 

commands on (table) 3-6 
Edit Notes command, flows pop-up menu, 
Workflow Design Editor 

description 3-14 



persistent storage 

cleaning A-5 
project directory 
definition of A-2 
files in A-3 
project directory structure (figure) A-2 
relationship to applications A-2, A-4 
relationship to tasks A-2, A-4 
supporting WFT Development 

Environment A-2 
task directories 
files in A-4 

after editing using Task Editor A-4 
WFT workflow systems directory structure 
(figure) A-2 
display elements 
creating predefined 6-63 
having focus, list 6-83 
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Edit Notes command, subworkflows pop-up 
menu, Workflow Design Editor 

description 3-17 
Edit Notes command, tasks pop-up menu, 
Workflow Design Editor 

description 3-13 
Edit Paths command, Project menu 

description 2-10 
Edit Predefined CD File List command, Project 
menu 

description 2-10 
Edit Routing CD File List command, Project menu 

description 2-10 
Edit Via Form tool, Form Editor 6-26 
edit windows 

accessing from dialog boxes 2-28 
Edit Workflow command, subworkflows pop-up 
menu, Workflow Design Editor 

description 3-17 

using 3-34 
editing 

applications 7-15 

assignment of tasks to simulation nodes 9-17 
attributes 4-72 ...... 

access 4-73 

applicability 4-74 

types 4-75 - - 

classes 4-25,4-28 • 

attachments 4-69 **■■*"" " 

attributes 4-72 I . . 

names 4-65 
form backgrounds 6-51 • : : " : r 

form close functions 6-50 
forms 6-16 . 
— menus in a form -6-49 : = 
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WFT File 
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Editors menu 
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creating 4-26 

introduction 4-26 
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Erase From Diagram command, tasks pop-up 
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using 3-28 
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editing server names 8-18 
editing WFT PATH objects 2-42 
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created by WFT Development 

Environment A-3 
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in node directories A-5 
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in task directories A-4 

after editing using Task Editor A-4 
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supporting WFT Development 
Environment A-2, A-3 
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creating 6-52 
Filled Circle tool, Form Editor 6-26 
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creating 6-52 
Filled Polyline tool, Form Editor 6-27 
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creating 6-55 
Find & Replace command, Edit menu, Class 
Editor 
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Find command, Edit menu, Class Editor * - - 

using 4-30 ^ 
Find Next command, Edit menu, Class Editor : > 
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using 4-30 
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using 3-19, 3-20, 3-26 
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creating 3-19 
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creating copy flows 3-20 
creating notes for 3-23 
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definition 3-3 



flows (cont) 
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using 6-83 
Form Editor 
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menus 6-80 
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focus links 
about 6-83, 6-84 
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selection group 6-81 
menus 6-22 

multiple selection capabilities 6-80 
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pop-up menus 6-35 
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creating 6-15 
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working with bitmaps in 6-72 
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setting in Class Editor 4-44 
associating callback functions with Form 
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callback 
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creating 4-78 

defining in Class Editor 4-42 
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defining parameters in Class Editor 4-45 
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deleting local attributes in Class Editor 4-46 
deleting parameters in Class Editor 4-45 
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Editor 4-46 
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Editor 4-46 
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Editor 4-46 

editing names*in Class Editor 4-42 - ~ , _ 

editing parameter names in Class Editor -4A5 ■ 
2 editing parameter types in Class Editor .445 r v : 
exported 

, ; s§ tting -inClass Editor 4-43 .;. 
exported external " 7 _ 7 ^ 

setting in Class Editor 4-43 . ~ J r . . 
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setting in Class Editor 4-43 ' y . . ; 

. .finding referenceato and from usin^Cl^ss^ j_ : 
. Editor 4-42 
inherited - 

redefining in Class Editor 4-42 
local attributes 

creating 4-80 

native 

setting in Class Editor 4-43 
parameters 

creating 4-79 
remote 

setting in Class Editor 4-43 
selecting local attribute types in Class 

Editor 4-46 
selecting parameter types in Class Editor 4-45 
setting form close functions 6-50 
setting kind in Class Editor 4-43 
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setting parameter kinds in Class Editor 4-45 
shared 

setting in Class Editor 4-43 
shared external 

setting in Class Editor 4-43 
shared native 

setting in Class Editor 4-43 
types 

setting in Class Editor 4-44 
Functions subwindow, Class Editor 
Functions tab, pop-up menu description 4-42 



General Help command, editor Help menus 

description 2-11 
Generate HTML command, Prq/ecfmenu 

description 2-10 
Generate Report command, tasks pop-up menu, 
Workflow Design Editor 

description 3-13 
generated files 

removing 
how to 2-39 
generating 

project files 2-38 

project reports 2-40 

reports 

how to 2-40 ~; 

grid 

in Workflow Design Editor 7 7 -. ' 

controlling 3-11 
grid lines 



-displaying in Class Editor subwindows 4-32" 
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Help menu 

commands provided on (table) 2-11 ~ 
hiding the Messages window 2-32 
host names 

specifying for business process nodes 8-16 

specifying for servers 8-16 
how to use this document 1-2 
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Icon Button tool, Form Editor 6-27 
icon buttons 

creating 6-57 
Include Child Classes command, classes pop-up 
menu, Object Model Editor 

description 4-14 



Include Child Classes command, relation 

attributes lines and inheritance lines 
pop-up menu, Object Model Editor 
description 4-16 
Include Parent Classes command, classes pop-up 
menu, Object Model Editor 
description 4-14 
Include Related Classes command, classes pop-up 
menu, Object Model Editor 
description 4-15 
Increment Version command, Work Items menu, 
Workflow Design Editor 
description 3-6 
indicator tools 
definition 2-14 
File Synchronization Tool 

description 2-14 
in WFT Development Environment 

description of 2-14 
Object Model Error Tool 

description 2-14 
Parse Tool 
description 2-14 
inference ....... 

definition 4-4 
infonAb^ _ . . 

"- definition 6-27 - - 

Inform Button Type command, Form Editor 

text entry line pop-up menu 6-40 
inheritance 
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Jnliefitahce command, Show menu, Object Mpdeb 
Editor t f ^ 

descriptiorT4-7 ~ ~~ 7~^T 
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description 4-15 ro ^ 

Inheritance Lines command, Styles menu, Object 
Model Editor 
description 4-8 : ; 
Inherited Attributes subwindow, Class Editor * 

Attributes tab, pop-up menu description '4-38*' 
inherited classes 

editing names 4-35 
Inherits From subwindow, Class Editor 

Class tab, pop-up menu description 4-35 
Instance Relation Attributes command, Show 
menu, Object Model Editor 
description 4-7 
instances 

specifying a flat number of simulation node 

instances 9-24 
specifying a scheduled number of simulation 

node instances 9-25 
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specifying instances of a simulation node 9-24 functions 
interactive searches creating 4-80 

how to use 2-30 Local Attributes subwindow, Class Editor 

in WFT Development Environment Functions tab, pop-up menu description 4-46 

description 2-30 log files 

keyboard commands (table) 2-31 appending messages to 2-33 

overwriting messages 2-33 
J specifying names 2-33 

Junction Box command, flows and junction boxes l°ggi n g messages to a file 2-33 

pop-up menu, Workflow Design Editor long Names command, Show menu, Workflow 

Attached cascade entry, description 3-15 Design Editor 

commands that cascade from 3-15 description 3-6 

description 3-15 ^ 

Separate cascade entry, description 3-1-5 M 
junction boxes managing 

conditions represented by 3-20 project cd files 2-41 

definition 3-19 match attributes 

in Workflow Design Editor definition 3-3 

pop-up menu for, commands on (table) 3-14 menus 
junction conditions cascade 

how represented 3-20 - description 2-23 

junctions - . „ Class Editor , „, 

definition 3-3 . . . description 4-29 . ^ , . - , ; . 

editing associated match attributes 3-14: • • : :: — - - - ^editing in a form 6-49 
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description 3-14 Form Editor tool box 6-31 - 7 -.7 

Hide cascade entry, description 3-14 Object Model Editor 4-14 

Show cascade entry, description 3-14 Task Editor 6-12\ 

Show Original Label cascade entry Use with multiple selection 6-80 . 

description 3-14 - Workflow Design Editor 3-12 - 

Labeled Box tool, Form Editor 6-28 Workflow Simulator Deployment View 

labeled boxes subwindow 9-12 

creating 6-53 Workflow Simulator Design 

layered tabs subwindow 9-15 

definition 2-35 pull-down 
line segment circles Application Editor 7-4 

definition 4-16 Class Editor 4-29 

pop-up menu for, Object Model Editor Deployment Editor 8-5 

description 4-16 description 2-22 

Une tool, Form Editor 6-26 Form &Q1 

lines Object Model Editor 4-6 

creatine 6-52 Schema Editor 5-5 

Task Editor 6-7 
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logging to files 
appending 2-33 
overwriting 2-33 
specifying the file name 2-33 
specifying whether logged to a file 2-33 
Messages command, T menu 

description 2-9 
Messages window 
description 2-31 
destroying 2-32 
hiding 2-32 
menus (table) 2-32 

message types displayed in (table) 2-31- 
specifying when displayed 2-33 
specifying when raised to front of display 2-33 
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file 2-33 

Messages Window command, Options menu 

description 2-11 
mouse cursors 

descriptions (table) 2-21 
movable dividers 

moving 2-30 

pane and column 
description 2-30 
moving 

attribute definitions 4-77 

Deployment Editor workspace elements 8-24 
0* Object Model Editor 

workspace elements 4-22 
moving business process nodes 8-24 



moving communication link labels 8-24 
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moving Deployment Editor workspace " 

elements 8-24 
moving servers 8-24 

moving workspace elements, Deployment 

Editor 8-24 
moving workspace elements, Workflow 

Simulator 9-30 
multiple selection 
about 6-80 

manipulating individual display elements in a 

selection group 6-81 
selecting multiple display elements 6-81 
use with pop-up menus 6-80 
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New Applications command, T menu 

description 2-9 
New Class tool, Object Model Editor 

description 4-9 - 



New command, Roles menu, Workflow Design 
Editor 
description 3-6 
New command, Schemas menu, Workflow Design 
Editor 
description 3-7 
New command, Work Items menu, Workflow 
Design Editor 
description 3-6 
New Flow tool, Workflow Design Editor 

description 3-9 
New Inheritance tool, Object Model Editor 
description 4-9 
using 4-20 

New Relation Attribute tool, Object Model Editor 
description 4-9 
using 4-19 

New Subworkflow tool, Workflow Design Editor 

description 3-9 
New Task tool, Workflow Design Editor 

description 3-9 
node arguments 

specifying, Deployment Editor.-&-19 .: 
node directories 

files in A-5 
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editing. Deployment Editor 8-18 
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Object Model Editor 
accessing 2-10,4-5 
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button 

description 4-10 
class symbols 
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descriptions 4-13 
classes 
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editing 4-25 

resizing symbols 4-25 
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description 4-11 

pop-up menu 

description 4-11 
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command 

description 4-11 
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command 

description 4t11 
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relation classes 

definition 5-2 
Relation Lines command, Styles menu, Object 
Model Editor 

description 4-8 
relation schemas 

creating 5-7 
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menu, Object Model Editor 
description 4-15 
Remove Child Classes command, relation 

attributes lines and inheritance lines 
pop-up menu, Object Model Editor 
description 4-16 
Remove command, Roles menu, Workflow Design 
Editor 
description 3-6 
Remove command, Work Items menu, Workflow 
Design Editor 
description 3-6 
Remove From Diagram command, classes pop-up 
menu, Object Model Editor 
description 4-14 
Remove From Diagram tool, Object Model Editor 

using 4-24 
Remove Generated Files utility button 

purpose 2-13 
Remove Generated Project Files command, T menu 

description 2-9 : " : 
Remove Parent Classes command, classes pop-up 
--■*"' menu; Object Modei Editor 

description 4-15 * ' 
Remove.Related Classes command, classes pop«up 4 ; 

menu, Object Model Editor 
■ : 'description" 4-15 
Remote todiy Fbm Mitbr fciti 
removing ~ 
cd files 2-44 r 
Object Mod pi Ed itor 



v workspace elements 4-22, 4-23, 4-24 
roles 3-28 7 " [ 

removing backup ^ nc^es f0^rveiC 8-17 
removing business process rtbde user names and 

' passwords 8-19 
removing generated files' 

how to 2-39 
removing processors associated with simulation 
nodes, Workflow Simulator Deployment 
View subwiridow 9-30 . 
removing processors from tasks in simulation 

nodes 9-32 
removing simulation nodes 9-31 
removing simulation nodes, Workflow Simulator 

Deployment View subwindow 9-30 
removing tasks from simulation nodes 9-31 
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removing tasks in simulation nodes, Workflow 
Simulator Deployment View 
subwindow 9-30 
removing user names and passwords, 

Deployment Editor 8-19 
removing work item creators associated with 
simulation nodes, Workflow Simulator 
Deployment View subwindow 9-30 
removing work item creators from tasks in 

simulation nodes 9-32 
removing workspace elements, Deployment 

Editor 8-16 
renaming 
classes 

attachments 4-69 
schemas 5-13 
Report command, T menu 
description 2-9 
Reports 
fy generating 

how to 2-40 
resetting simulations 9-29 
resizing 
classes 
symbols 4-25 
resizing subworkflow symbols in Workflow 

Simulator Design View subwindow 9-32 
resizing symbols in Workflow Simulator Design 

View subwindow 9-32 
resizing task symbols in Workflow Simulator 

Design View subwindow 9-32 
resizing the workspace 

Auto Size Workspace command 2-1 6 
resizing windows 2-15 
resizing workspace 2-15 
Restore Default Size command, Form Editor 



Role Editor 

accessing 3-22, 3-23 

creating roles 3-22 

editing roles 3-23 

purpose 3-22 
roles 

associating with tasks 3-23 

creating 3-22 

definition 3-3, 3-22 

editing 3-23 

removing 3-28 
Roles command, Show menu, Workflow Design 
Editor 

description 3-6 
Roles menu, Workflow Design Editor 

commands on (table) 3-6 
routing 

custom 3-31 - - 

attribute value rules 3-32 
custom rules 3-32 
external rules 3-31 
no rules 3-33 
routing cd files 

adding 2-43 - re - 

routing rules 

."*". definition 3r3, 4r4 - >r;v; ; " ; 

rules" 

adding attachments in Class Editor 4-51 
. : defining in Class Editor 4-49 

definition 4-4-' • j 
deleting attachments in Class Editor 4-51 • 
deleting irt^lass Editor 4-49 - : 

; -'.editing attachment names in Class Editor 4-51 
: ^editing attachment text in Class Editor 4-51 

editing names in Class Editor 4-49 
: - finding references to and from using Class 

: i;:Editor^4r49 
: ~ .nouting,llefinition 3-3,4-4 
Rules subwindow, Class Editor 

Rules tab, pop-up menu description 4-49 
Rules tab, Glass Editor ^ 
pop-up menus 
description 4-49 
running 
nodes 8-21 
servers 8*21 
simulations 9-28 
run-time workflow systems 
files supporting A-2 . - 



button pop-up menu 6-40 
icon button pop-up menu 6-41 
Restore Default Size command, subworkflows 

pop-up menu, Workflow Design Editor 
description 3-17 
Restore Default Size command, tasks pop-up 
menu, Workflow Design Editor 
description 3-13 
Return to Sender command, flows pop-up menu, 
Workflow Design Editor 
Allowed cascade entry, description 3-15 
commands that cascade from 3-15 
description 3-15 

Not Allowed cascade entry, description 3-15 
Reuse Window command, Options menu 
description 2-11 



20 Using the WFT Development Environment 



Index 



Save and Build utility button 

purpose 2-13 
Save and Generate Project Files command, T menu 

description 2-9 
Save command, T menu 

description 2-9 
Save utility button 

purpose 2-13 
saving 

entity-relationship diagrams 4-26 
WFT workflow system data 2-38 
Schema Editor 
accessing 2-10,5-4 
commands on Schema menu 5-5 
creating schemas 5-10 
definition of related terms 5-3 
displaying Schema List subwindow 5-5 
introduction 5-2 
menus 5-5 

moving to topmost schema in tree 5-7 
prerequisites to using 5-2 
purpose 2-12 

relation attributes pop-up menu 

description 5-7 
relation schema pop-up menu ; ~- 

description 5-7 ■ 
relation schemas : 

specifying 5-12 
Schema List subwindow 
description 5-8 

columns 5-8 50: ":: 

displaying 5-14 : 
hiding 5-14 ; * ; 

Schema menu . 
description 5-5 



Schema subwindow 
description 5-6 
buttons 5-7 
columns 5-6 
pop-up menu 5-7,5-9 
schemas 
deleting 5-13 
editing 5-11 
renaming 5-13 
schemas pop-up menu, Schema List 
subwindow 
description 5-9 
subwindows 5-5 
description 5-6 
Schema Editor command, Editors menu 
description 2-10 



Schema List subwindow 
description 5-8 
columns 5-8 
displaying 5-14 
hiding 5-14 
Schema List subwindow, Schema Editor 

displaying 5-5 
Schema menu, Schema Editor 

description 5-5 
Schema subwindow 
description 5-6 
buttons 5-7 
columns 5-6 
pop-up menu 5-7,5-9 
schema trees 
definition 5-2 

moving to top in Schema Editor 5-7 
reading 5-9 
schemas 
creating 5-10 
creating and editing 

accessing the Schema Editor 2-12 
creating for types of work items 3-20 
default, when generated 3-22 
definition 3-3,5-2 
^deleting 5-9^ " ■ - * < 

- deselecting all attributes of selected class 5-5" 
■-..■editing:-5-ll*v-"'' ii: 
;:' editing for typ^ of work items 3-21 * " '7 
; L including-relatioh attributes by reference 5^71 

Leading schema trees 1 5^9 ~- :r 
relation 

: : creating: 3^7' t -\ ^;.^ ""iinr 
~ definition 5-2 ^ : -iv. 

. ■ • editing 5-7 ^ v ~ ~ 
selecting 5-7 



M-r:- specifyirtg 5-12 -vpc-.p ~ ** 
T renaming 5^?r^l3 ' 
! selecting all attributes of selected class 5 r 5 

selecting for typesbf ^work-items 3-21 
i trees . ■ 

readmg £-9- ; : .. 
what they include 5-2 
Schemas menu, Workflow Design Editor 

commands on (table) 3-7 
scr611bars 
in Workspace, Workflow Design Editor 
^ when they appear 3-1 1 
searches 
interactive 
description 2-30 
how to use 2-30 
keyboard commands 2-31 
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searching 

interactively for strings 2-30 
Select command, Form Editor 

icon button pop-up menu 6-41 
Select command, Schcmas menu, Workflow 
Design Editor 

description 3-7 
Select tool, Form Editor 6-26 
selecting directories 

using fije selection boxes 2-28 
selecting files 

using file selection boxes 2-28 
selectors 

Class, Object, Attribute 
see CO A selectors 
server paths 

showing, Deployment Editor 8-17 
Server Types buttons 

description of 8-9 
servers 

building 8-20 

cleaning persistent storage 8-22 
creating 7-12,8-14 
creating backup nodes for 8-17 
debugging 8-22 

removing backup nodes for 8-17 
running 8-21 

showing information 8-20 
specifying arguments 8-19 t 
specifying host names 8-16 r:: 
specifying types of services provided 8-15 
services 

specifying types a server provides 8-15 
Set Bitmap File command, subworkflows pop-lip 
menu, Workflow Design Editor 
description 3-17 



setting backup communication protocol values 

for links 8-23 
setting communication protocol values for 

links 8-23, 8-24 
setting simulation start and end times 9-27 
Show in Diagram command, Classes list box pop- 
up menu, Object Model Editor 

description 4-11 
Show menu, Object Model Editor 

description 4-7 
Show menu, Workflow Design Editor 

commands on (table) 3-6 
showing communication link labels 8-23 
showing node and server information, 

Deployment Editor 8-20 
showing server paths, Deployment Editor 8-17 
simulation buttons 

description 9-8 
simulation clock display area 

description of 9-9 
simulation end times 

setting 9-27 
simulation nodes 

creating 9-16 

editing polling interval 9-23 
editing the assignment of tasks 9-17 
removing 9-31 
removing'tasks from 9-31 
sp<^fying'a*te 9-24 
speafyihg a scheduled number of 

mstahces^ ;vr-;::r 
: spedfym^ ^ 
1 simttlatibn start times 

$irnulalrions T -> ; ~ 
creating and running 



Set Bitmap File command, tasks pop-up menu A ~ ~ 
Workflow Design Editor 
description 3-13 
Set Prompt Width command, Form Editor n " 

text entry line pop-up menu 6-39 
Set Roles command, tasks pop-up menu, 
Workflow Design Editor 
description 3-13 
using 3-23 

Set to Default Schema command, Schemas menu, ^ 
Workflow Design Editor 
description 3-7 
using 3-22 
Set Workspace Size command, Edit menu, 
Workflow Design Editor 
description 3-6 
sets 

work item, definition 3-3 



r '•; - tactgssing the Workflow Simulator 2-12 
r yii ]. resetting 9^2f : " - -~ * : : """" ~ - 

/'* ; ™nning'''9-2&" - " J ' 
''■^ "SSttm^ start and end times 9-27 

"' stepping; 9-28 
: stopping 9-29 

SNAP Development Environment 
how to access 2-45 
invoking to edit applications 7-15 
invoking to edit tasks 6-14, 7-15 
SNAP Language Errors window 
accessing 2-17- 
description 2-17 
pop-up menu for errors 

description (table) 2-18 
T menu 

description (table) 2-18 
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sorting 
multicolumn 

in Class Editor tabs 4-33 
values in Class Editor columns 4-32, 4-33 
specifying command-line arguments for nodes, 

Deployment Editor 8-19 
specifying command-line arguments for servers, 

Deployment Editor 8-19 
specifying directory names 

using file selection boxes 2-28 
specifying file names 

using file selection boxes 2-28 
specifying flat quantities of simulation 

nodes 9-24 
specifying host names 
for business process nodes 8-16 
for servers 8-16 
specifying output work item creations 9-21 
specifying persistent storage for business process 

nodes, Deployment Editor 8-20 
specifying quantities of simulation nodes 9-24 
specifying scheduled quantities of simulation 

nodes 9-25 
Spin Box tool, Form Editor 6-28 
spin boxes 
creating 6-59 
resizing 6-60 
setting values for 6-59 
turning on autowrapping 6-60 
turning on left alignment 6-61 
Split Flow Segment command, flows pop-up i; 
menu, Workflow Design Editor 
description 3-14 a 
Split Line command, relation attributes lines and 
inheritance lines pop-up menu, Object - 
Model Editor 

— des cription 4-16 : : nrr 

Static Relation Attributes command, Show menu, 
Object Model Editor 
description 4-7 
status line - 
in WFT Development Environment 
description 2-15 . 4 

stepping simulations 9-28 
stopping simulations 9-29 
styles 

defining for flows 3-29 

defining for tasks 3-29 

denning in Workflow Design Editor 3-29 

see also contexts 
Styles menu, Object Model Editor 

description 4-8 
Styles menu, Workflow Design Editor 

commands on (table) 3-7 



subclasses , 

definition 4-4 
subworkflows 

creating 3-25 

creating flows between 3-25 
creating notes for 3-23 
definition 3-3 
displaying 3-33,6-19 
editing 3-33 
^ in Workflow Design Editor 

pop-up menu for, commands on (table) 3-17 
moving between workflows 3-34 
purpose 3-25 



tab bars 

definition 2-35 
tab labels 

definition 2-35 
tab windows 
how they work 2-35 
in WFT Development Environment 

description 2-35 
order of tabs 2-35 
tabs 
bars 

definition 2-35~ 
Class Editor 
Attributes tab 4-37 
Class tab 
- *~ description 4-34 
; " r Constants tab 4-59 
: " Demons tarr-4-52 
description 4-32 
functions tab 4-41 
Patterns tab 4-62 




tab 4-48 " 5 ' 
: .' ~\ Types tab 4r^6 ~ 

labels - r 
'' ^definition 2-35" " ? 
layered — - 
dermitiori 2-35 
ordering of 2-35 
Task command, Styles menu, Workflow Design 
Editor 
description 3-7 
using 3-18 
task directories 
files in A-4 
after editing using Task Editor A-4 
Task Editor 
accessing 6-6 

accessing the Form Editor 6-15, 6-16, 6-21 
associating forms with tasks 6-16 
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Task Editor (cont.) 
building tasks 6-14 
cleaning a task 6-14 
creating forms 6-15 
Design Hierarchy list box 6-10 
editing forms 6-16 
editing tasks 6-14 
introduction to 6-2 
menus 6-7 
pop-up menus 6-12 
purpose 2-12 

removing forms from tasks 6-17 
removing forms from the workflow 

j system 6-18 
replacing forms associated with work items in 

tasks 6-18 
tool box 6-8 
tools 6-9 

Work Item Forms list box 6-10 

workspace 6-11 
Task Editor command, Editors menu 

description 2-10 
tasks 

adding work item creators 9-17 
adding work item processors 9-20 
associating forms with 6-16 
associating roles with 3-23 
associating with business process 

applications 7-12. 
building 6-14, 7-14 
cleaning 6-14,7-14 
creating 3-18 
creating notes for 3-23 
defining styles for 3-29 
definition 3-3 
editing 6-14,7-15 



text (cont.) 
pop-up menu for, Object Model Editor 
description 4-17 
text entry lines 
creating 6-58 
entering values 2-27 
in WFT Development Environment 

description 2-27 
inform buttons 
description 2-27 
kinds 2-27 
labels 

description 2-27 
prompts 
description 2-27 
Text Entry tool, Form Editor 6-27 
Text tool, Form Editor 6-27 
This 1-5 

Tool Box Context display 

description of 6-30 
Tool Box Context tool, Form Editor 6-26 
tool boxes 
Application Editor- 7-5 
definition 2-25 
Deployment Editor 8-6 
- Form Editor- 6-25 ■ r - 1 : 
. .Object Model Edftm •; 4-8, .. 
Task Editor 6-8 
< Workflow Design Editor, example 3-8 
: 7 Workflow Sim ulator-r9-6- ~ - 
- tools:;;" 1: /: j 

'Application: Editor 7-6 
j re definition 2-26 

Deployment Editor 8-7 
— Form Editor 6-26 
indicator 



editing the assignment to simulation 

nodes 9-17 
in Workflow Design Editor 

pop-up menu for, commands on (table) 3-13 
moving between workflows 3-34 
relationship of directories to A-2, A-4 
removing forms from 6-17 
removing from business process 

applications 7-13 
removing from simulation nodes 9-31 
removing work item creators and 

processors 9-32 
replacing forms associated with work 

items 6-18 
Tasks list box, Application Editor 7-7 
text 
creating 6-57 

creating in workflow designs 3-24 



: redefinition 2-14 

- indicator tools - 

- description of (table) 2-14 
Object Model Editor 
New Class 

description 4-9 
New Inheritance 

description 4^9 
New Relation Attribute ~- 
description 4-9 
Task Editor 6-9 
using 2-26 . . : _ 

Workflow Design Editor (table) 3-9, 9-7 
trees 

schema, definition 5-2 
types 

adding attachments in Class Editor 4-58 
adding in Class Editor 4-57 
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types (cont.) Ven/y utility button 
definition 4-4 purpose 2-13 

deleting attachments in Class Editor 4-58 verifying 
deleting in Class Editor 4-57 projects 2-40 

editing attachment names in Class Editor 4-58 virtual workspace, Workflow Desien Editor 

editing attachment text in Class Editor 4-58 printing 3-11 

editing names in Class Editor 4-57 

editing types in Class Editor 4-58 W 

finding references to and from using Class WDE 

Editor 4-57 see Workflow Design Editor 

setting access levels in Class Editor 4-57 w f env prograrn 

Types subwindow, Class Editor starh the WFf Development 

Types tab, pop-up menu description 4-57 Environment 2-3 

Types tab, Class Editor WFT Development Environment 

pop-up menus cascade menus 

description 4-57 description 2-23 

check buttons 
description 2-23 

Undo command, Edit menu, Class Editor COA selectors 

using 4-30 how to use 2-37 

urikn own COA selectors, description 2-36 

specifying as value 2-28 dialog boxes 

User Manuals command, editor Help menus . description 2-28 

description 2-11 directories supporting A-2 

user names and passwords drag and drop 

adding, Deployment Editor 8-18 ' -TUsirig 2-26 

removing, Deployment Editor 8-19 .... , editors 

utility burtons - - accessing 2-19 

description 2-13 f[\ e selection boxes 

in WFT Development Environment ^ *■ Vi " ' tfescf iption 2-28 
description 2-13 r."ci.:"r Mwtouse 2-29 

Remove Generated Files ■ : - ^ files created by A-3 

purpose 2-13 : : Vr i w / - files supporting A-2, A-3 

$ ave rroul 1 indicator tools 

purpose 2-13 ^description of 2-14 

Save and Build "**;;'"'•"" ,- interactive searches ^ 

purpose 2^13 ~ — w.-I yi^i description 2-30 

Veri f!f . : " ^.....\. introduction 2-2 

purpose 2-13 \y: i Reyboafd^uivalents 

~ rr l 2 description 2-23 
^ main window - 

variables editor buttons 2-12 

defining in Class Editor 4-50 main window, about the 2-8 

deleting in Class Editor 4-50 movable pane and column dividers 

editing names in Class Editor 4-50 " description 2-30 

editing names of referenced classes in Class pop-up menus 

Editor 4-50 ' description 2-22 

Variables subwindow, Class Editor pulldown menus 

Demons tab, pop-up menu description 4-54 description 2-22 

Rules tab, pop-up menu description 4-50 ^quitting 2-45 

Verify command, T menu radio buttons 

description 2-9 description 2-24 
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WFT Development Environment (cont.) 
SNAP Language Errors window 
description 2-17 
pop-up menu for errors 

description (table) 2-18 
T menu 

description (table) 2-18 
starting 2-3 

wfenv program 2-3 
status line 

description 2-15 
tab windows 

description 2-35 
text entry lines 
description 2-27 
inform buttons 

description 2-27 
kinds 2-27 
labels 

description 2-27 
prompts 

description 2-27 
utility buttons 

description 2-13 
workspace 
definition 2-8 
WFT File Editor 
accessing 2-10 
when to use 2-41 
WFT PATH Editor 
accessing 2-10 
when to use 2-41 
WFT PATH objects 
about 2-41 
creating 2-42 
editing 2-42 



WM project structure 

introduction to A-2 
WFT workflow systems 

creating 2-3 

directory structures of (figure) A-2 

removing forms from 6-18 
wild cards 

using in file selection boxes 2-29 
windows 

resizing 2-15 
work item creators 

adding to tasks 9-17 

editing 9-23 

removing from tasks 9-32 
Work Item Forms list box, Task Editor 6-10 
work item processors 

adding to tasks 9-20 

editing 9-23 



work item processors (con/.) 

removing from tasks 9-32 
work item sets 

definition 3-3 

represented via junction boxes 3-19 
work items 

changing the type associated with a flow 3-29 
creating schemas for types of 3-20 
creating types of 3-18 
definition 3-3 

editing schemas for types of 3-21 

removing types of 3-28 

replacing forms associated with 6-18 

selecting schemas for types of 3-21 
Work Items list box, Workflow Design Editor 

description 3-10 
Work Items menu, Workflow Design Editor 

commands on (table) 3-6 
Workflow Design Editor 

accessing 2-10,3-5 

associating roles with tasks 3-23 

Clrnnge Flow Work Item Type command, flows 
pop-up menu 
description. 3-14 
using 3-29 

Omhge Flow/Work Item command, Styles menu 
using 3-29 

^Cimnge Style command, text and workspace 

~t "' _ P°P~ U R menu 
description 3-16 

Change Style command, text pop-up menu 

using "3 : 33~ - : -- v ; 
Change Workflow command, subworkflows- - 
pop-up menu ^ 
description 3-17 
usinjr 3 : 34 



Change Workflow ^rii^; t3^pop-up 
"C description 3-13 

; "'."using. 3-34 ~ 
changing the work item type associated with a 

flow 3-29 
controlling the grid 3-11 
creating 
compound flows 3-19 
copy flows 3-20 
flows 3-19 

flows between workflows 3-25 
notes 3-23 
roles 3-22 

schemas for types of work items 3-20 
subworkflows 3-25 
tasks 3-18 
text 3-24 
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Workflow Design Editor 
creating (cortt.) 

types of work items 3-18 
Custom Routing command, flows pop-up menu 
commands that cascade from 3-15 
description 3-15 
Custom Routing>Attributc Value Rule 
command, flows pop-up menu 
using 3-32 

Custom Routing>Cttstom Rule command, flows 
pop-up menu 
using 3-32 

Custom Routing>External Rule command, flows 
pop-up menu 
using 3-31 

Custom Routing>Nonc command, flows pop-up 
using 3-33 

defining styles for workspace elements 3-29 
definitions of important terms related to 3-3 
Design Hierarchy list box, description 3-11 
Do Not Use Bitmap File command, 
subworkflows pop-up menu 
description 3-17 
. Do Not Use Bitmap File command, tasks pop-up 
menu 
description 3-13 
Edit junction command, junction boxes pop-up 
menu ... 
description 3-14 . . . v 

Edit Notes command, flows pop-up menu 

description 3-14 
Edit Notes command, subworkflows pop-ufh- ._■ : 
menu , <, 

description 3-17 
Edit Notes command, tasks pop-up menu ~ 
description 3-13 



Edi t Wor kflo w c ommand , su bworkftow s -p op-,; 
up menu - - - 

description 3-17 ™ 
using 3-34 - 

editing roles 3-23 

editing schemas for types of work items 3-21 
editing subworkflows 3-33 
editing workflows 3-33 
Erase From Diagram command, tasks pop-up 
menu 
description 3-13 
example (figure) 3-5 

Generate Report command, tasks pop-up menu 

description 3-13 
introduction 3-2 
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Workflow Design Editor (cont.) 
Junction Box command, flows and junction 
boxes pop-up menu 

commands that cascade from 3-15 

description 3-15 
Label command, flows pop-up menu 

commands that cascade from 3-14 

description 3-14 
menus (tables) 3-6 
moving subworkflows between 

workflows 3-34 
moving tasks' between workflows 3-34 
notes created via 

how used 3-24 
pop-up menus 3-12 

for descriptive text 3-16 

for flow line segment circles 3-16 

for flows 3-14 

for junction boxes 3-14 

for subworkflows 3-17 

for tasks 3-13 

for workspace 3-16 
prerequisites to using 3-2 
purpose 2-12,3-2 
relocating flows 3-31 

Remove From Diagram command, tasks pop-up 

..menu 

.. using. 3-28 

removing \ 

roles 3-28 " 
- wtfrk item types 3-28 - ; ; 

- . workspace elements 3-27 
; L ■. workspace elements from diagram ; . : : 
: only 3-28 
Restore Default Size command, subworkflows: 
•popmprnenu 




description 3-17 . I* ^77T777~ 
Restore Defaidi$ize':commar\d, tasks pop-up 
^r-menu ^j v, ^. --"-i - . .• , : ; 

description 3-13 ■ 
Retufn to Sender command, flows pop-up ~ * 
menu : 

commands that cascade from 3-15 

description 3-15 
routing rules, attribute value 3-32 
routing rules, custom 3-32 y 
routing rules, external 3-31 
routing rules, none 3-33 
routing, custom 3-31 

selecting schemas for types of work items 3-21 
Set Bitmap File command, subworkflows pop- 
up menu 
description 3-17 
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Workflow Design Editor (cont.) 
Set Bitmap File command, tasks pop-up menu 

description 3-13 
Set Roles command, tasks pop-up menu 

description 3-13 

using 3-23 

Set to Default Schema command, Schemas menu 
using 3-22 

Split Flow Segment command, flows pop-up 
menu 

description 3-14 
Task command, Styles menu 

using 3-29 
tool box example 3-8 
tools (table) 3-9, 9-7 
what you can do 3-2 
Work Items list box, description 3-10 
workspace 

definition 3-11 

display elements that have pop-up 

menus 3-12 
when scroll bars appear 3-11 
Workflow Design Editor command, Editors menu 

description 2-10 
workflow designs 
creating and editing 

accessing the Workflow Design Editor 2-12 
creating text 3-24 
definition 3-2, 3-4 
how used 3-24 
Workflow Simulator 
accessing 2-10, 9-4 

adding work item creators to tasks 9-17 
adding work item processors to tasks 9-20 

real time versus elapsed time 9-20 
creating simulation nodes 9-16 
Deployment View subwindow 9-11 

pop-up menus 9-12 
Design subwindow 9-14 

pop-up menus 9-15 
editing a simulation node's polling 

interval 9-23 
editing the assignment of tasks to simulation 

nodes 9-17 
editing work item creators and 

processors 9-23 
introduction to 9-2 
moving workspace elements 9-30 
purpose 2-12 

removing simulation nodes 9-31 
removing tasks from simulation nodes 9-31 
removing work item creators and processors 
from tasks 9-32 



Workflow Simulator (cont,) 

removing workspace elements from the 
Deployment View subwindow 9-30 

resetting simulations 9-29 

running simulations 9-28 

setting simulation start and end times 9-27 

simulation buttons 9-8 

simulation clock display area 9-9 

specifying a flat number of node 
instances 9-24 

specifying a scheduled number of node 
instances 9-25 

specifying a simulation node's instances 9-24 

specifying coincidental creations 9-18 

specifying output work item creations 9-21 

stepping simulations 9-28 

stopping simulations 9-29 

tool box 9-6 

Workflows list box 9-10 
Workflow Simulator command, Editors menu 

description 2-10 
workflow systems 

definition 3-4 
workflows : 

creating 3-25 

creating flows between 3-25 
creating notes for 3-23 
displaying 3-33,6-19 
editing 3-33 

moving subworkflows between 3-34 

moving tasks between 3-34 
Workflows list box 9-10 
workspace 

Application Editor 7-8 
— contents - 

how to print 2-41 

printing 2-41 
definition 2-8,2-15 
Deployment Editor 8-10 
Form Editor 6-34 
in Workflow Design Editor 

pop-up menu for, commands on (table) 3-16 
Object Model Editor 4-12 
printing contents 4-12 
resizing 2-15 

using Auto Size Workspace command 2-16 
Task Editor 6-11 
Workflow Design Editor 

definition 3-11 

resizing 3-11 
workspace elements 
Application Editor 

moving 7-13 
moving in Workflow Simulator 9-30 
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workspace elements (conl.) 
Object Model Editor 
defining styles 4-24 
moving 4-22 
removing 4-22,4-23,4-24 
removing from Deployment Editor 8-16 
removing from Form Editor 6-74 
removing from Workflow Design Editor 3-27 
removing from Workflow Design Editor 

diagram only 3-28 
removing from Workflow Simulator 9-30 
workspace elements, Deployment Editor 

moving 8-24 
Workspace Size Editor 
accessing 2-15 
description 2-15 
using 2-15 
workspace, Workflow Design Editor 
display elements 

that have pop-up menus 3-12 
example (figure) 3-12 
virtual 

printing 3-11 
when scroll bars appear 3-11 
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Overview 



To support teams of analysts, architects, and engineers 
practicing controlled iterative development, the software: 

• Enables each developer to operate in a private workspace 
containing the full model with exclusive control over the 
propagation of changes into that workspace, 

. . • Supports decomposition of the model into controlled 

units and integrates with any project-wide Configuration 
. Management (CM) system to maintain the integrity of 
those controlled units. 

• Uses platform-independent model files for persistent 
Storage of controlled units, and provides the path map 

; : in^hanisih to.^ , 
Vambng .workspaces, and archives. 

Controlled fteiative Development 

* . / through . a sequence of iterations. Each iteration begins with 
an assessment of the current analysis, design, and * • " - . 
implementation to idemiiy crtflc^, tinresolved risks; v . .. 

most critical- unresolved risks are ,v 

Scenarios illustrating the risks are identified, and the current 
analysis and design are extended to address the risks. , ; 

To provide objectivCproof that the targeted risks have been 
retired, the current implementation is extended— as 
minimally as possible — and tests organized around the risk 
scenarios are constructed. It is common for the design to 
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evolve during extension of the impiementaticn^-for example, 
new operations may be added, or several classes may be 
relocated from one logical package to another to strengthen 
ah abstraction. 

When the extended implementation successfully executes all 
tests, the implementation is reviewed and, if acceptable, the 
analysis and design model is updated to reflect" the design 
changes instituted in the implementation. When this update 
is complete, the next iteration proceeds. 

The controlled iterative development process is shown 
graphically below: . ; ; ... 

initial requirements 

./•... .■, t ■ 

• i ■ '. ■> . analysis & design ■ . ■ 



assessment risk targeting 

V" : %. t implementation & testing 



f 

Setting Up Multiuser Iterative Development 



This section provides ste£-by-step instructions for settingmp 
a multiuser development and .«ecuting\anjteratlqn.. l^ie 
process implied by these steps is representative, with many 
variations possible to support yotir specific process. In 
particular, this process assumes that ea:ch controlled unit is 
owned by one developer — a developer can own several 
controlled units, but no controlled unit is owned by more 
than one developer. The process further assumes it is 
financially worthwhile to allocate to each developer sufficient 
filesys tern storage to maintain in their workspace a full copy 
of all bontroiled units. Both of these assumptions can be 
relaxed if appropriate. 
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Subsequent sections of this chapter provide additional 
information about controlled units, the path map 
mechanism, and integration with a configuration 
management system. 

To set up multiuser development with Rose: 

1 . Select a filesystem directory to represent each 
developer's workspace, and choose a virtual path 
symbol— such as $mywork— to represent the root of 
the workspace directory hierarchy. Create a path map 
entry in each developer's .ini file; this entry should 
map the virtual path symbol $mywork to the actual 
pathname of the user's workspace directory: 

[Virtual Path Map.] 

mywork=:e : Vpro.ject\userriame\work6pce . ... 

With this setup, Rose will construct $mywork-relative 
filenames in all model files, allowing :these model files 
to be moved or copied among workspaces and 
archives. 

Rose updates its -path map with changes made to the: 
.mi .file whenever Open from the File command is 
; . .-exfecuted; ^ v . ; 

to represent the 
- ,ihtegratlon workspace, imd setup^ 

: : Use. this -Ini file wheriever you are operating in the 
integration workspace. , ' ' / ' ' ' ' " 
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Establish a script : and. a Rqse CM menu entry ipr each . 
configuration management operation, such" as 
■ Control, Checkout, Checkln; and AqceptChanges: Hie 

software includes basic scripts for use with a 
configuration management system popular on your . 
platform; you can use these scripts "as is/' extend 
them, or use them as a guide when creating scripts for 
use with your cpnfiguration management system. 
Additional information is provided in the section of 
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this chapter entitled Integrating With a Configuration 
Management System. . . . 

Create an initial model in the integration workspace, 
and decide which logical and component packages in 
this model represent appropriate elements for parallel 
development. Use Rose's File:Units:Control command to 
designate each such element as a controlled unit, and 
create its associated model file (.cat file) in your 
integration workspace directory. The model itself is 
also an element to be controlled. Use Rose's 
File:Un!ts:CM command to direct your configuration 
management system to. control each controlled unit. 

Set the integration workspace model's Design-level 
Directory code generation property to .the source code 
directory within the integration workspace! The name 
of this source code directory s.houlcj be specified using 
the virtual path: symbol $mywork. Generate code from 
the initial model to establish an implementation [ ! 7 . 
directory hief^chy/tath^ 

,.Jlose Mil generate ; a;physical rnocjel from the. logical 
package hierarchy If the initial model does not contain 
component packages. You may also wish to establish 
integration Workspace directories 
specifications, plans, documentation, arid tests. 

Direct your configuration management syisteni to 
control each source code unit, as well as 



specifications, plans, documents and tests you deem 
appropriate; these latter artifacts are referred to as 
auxiliary units. 

In the integration workspace", creiate a Project for the 
Rational/C++ Analyzer, specifying the Base Projects, 
Directories, Extensions, Files, and Export Options 
required to Reverse Engineer your source code during 
each iteration. Additional information is provided in 
the Round Trip Engineering with Rational Rose 4.0 
manual. ...= ... ........ 

Capture this initial state by directing your 
configuration management system to construct a 
release of all units it controls. Initialize the developer 
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workspaces by copying the integration workspace 
directory hierarchy and files to each developer 
working directory. 



Practicing Iterative Development 



After completing the five steps described in the previous 
section, your team can begin an iteration. The typical 
iteration will proceed through six phases: 

Planning In the integration workspace: 

• Identify risks. 

• * Establish iteration objectives and 

schedules. 

• Capture new scenarios and plan their tests. 

Propagation In the integration workspace: ~ ' '■" - 

• . Propagate controlled units from the 

integration workspace intd each developer 
workspace. 

. Propagate implementation source code and 
auxiliary units from the integration 
. . workspace into each developer workspace. 

Extension ' In.* the* developer .wbrtepaces:^* .. . . ■ 

: . * Extend the current implementation source 

'■\ r ; ' -v code- ': i '? r ^^V: - r: ^ 

• Extend the cuireiit scenario, tests, jarid 
. ; . verify their successful execution. 

Integration' In^the^tegration- 



; ? Accept all modified pqntrolled units into 
the integration workspace.* 

♦ ^ 'Accept all modified implerhentatiori source 

code units and auxiliary units into the 
integration workspace. 

• Identify and resolve inconsistencies. 
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Assessment 



Release 



• Verily successful execution of all scenario 
tests and regression tests. 

In the integration workspace: 

• Identify and validate design changes 
introduced during implementation. 

• Assess iteration results vs. established 
objectives. 

• Update analysis and design model to reflect 

• design changes. 

In the integration workspace: 

• Create a comprehensive iteration release. 



Planning Phase 



in the Planning phas£, use interaction -diagrams to capture 
the Scenarios that drive the iteration; . 



Propagation Phase 



In the Propagation phase, use the Fite:Units;CM command.to 
cjirectyour configuration management system, to 
AcceptChanges frtnh each controlled Unit; source code Unit, 
and auxiliary unit in the Integration W 
developer workspace. You can create a PropagateAll script 
that automates this step if desired. If your config uration J 



management system does not automatically construct 
directories when it accepts charges, create tbese directories 
manually, 



, Extension Phase 



During the Extension phase, each developer operates in 
his/her own workspace, loading those controlled units they 
need to reference or modify/ Before modifying a controlled 
unit, a developer must use the File:Units:CM command to 
Checkout that unit. Rose's write-protection mechanism 
prevents a developer from attempting to modify a controlled 
unit that has not been successfully checked out. 
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Developers can use Rose Code Generation to support source 
code extension for model components they create in his/her 
workspaces; after generating code for new components, direct 
the configuration management system to control the new 
source code units. If an existing class is re-assigned from one 
module to another, relocate any existing source— using the 
configuration management system as appropriate— before 
generating code for the class. 

If one developer encounters the need to modify a model 
component contained in a controlled unit assigned to another 
developer, there are two basic procedures that can be used 
depending on your process: 

• The developer needing Che change makes the change: 
check-out the controlled unit, make the changes in your 

. . workspace, and check the unit back. in;, the unit's owner 

will have to AcceptChanges from your workspace before 
Checking the unit out. 

• the developer owning the controlled unit makes the : " " ' 
change: ask the owner to-make the changes in their 

workspace arid check-in the controlled unit; then 
- AcceptChanges ihto youi* workspace. ' 

Developers can reverse engineer the source code in their 
workspace using the Rose Analyzer's FIrstLook Or BetalledAnalysfs 

v, ; ^ort: r Option Se^, and examine the resulting model with 
Rose. When satisfied, you can reyerse engineer the source 

• 9° d? Analyzer's RcwndTrtp Export Options Set, arid 

'use'Rcise's WeiMerge cbmmarid" ^update your workspace : .' 
model for consistency with its source, code. Be sure to inspect 
the log entries produced by the merge. : .- ~. - ; - 



Each developer should use the Tools:CheckModel 



command to- 



ed 



identify inconsistencies within their Workspace; ail such 
- inconsistencies must be.eliminated before proceeding to 
Integration. , If necessary, a developer can update his /her 
workspace with the most-recently checked-in version of a 
controlled unit by using the File:Units^M command to execute 
the AcceptChanges command. 



Rose 



=■ 
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Integration Phase 



In the Integration phase, load all controlled units in the 
integration workspace, and AcceptChanges for each unit 
modified in the iteration; you can create an AcceptAJl script 
that automates this step if desired. Use Rose's Tools:CheckModel 
command to identify inconsistencies introduced, by the 
integration of units extended in parallel. Accept all modified 
source code units and auxiliary units from developer 
workspaces. If your configuration management system does 
not automatically construct directories when .it accepts' 
changes, create these directories manually. Verify successful 
execution of all scenario and regression tests before 
proceeding to Assessment. 



Assessment Phase 



In the; Assessment phase, reverse engineer the source code in 
the Integration workspace using the Rose Analyzes firsiLooV 
,. ? r Preanalysis Export Option Set. and examine the 
resulting model with Rose, Use' Tp^s:SrSwbfere^! yrr^ ; - - 
design changes by comparing the reverse engineered model 
with the integration workspace, model. Additional information 
about model differencing is provided in the Model Differencinq 
chapter of this book. . ./.." . . . 

When you are satisfied with the iteration, reverse engineer 
-the source code wiUi the Analyzer's RoundTrlp Export Options 
Set, and use Rose's File:Merge command to update the 
integration workspace model for consistency with its source 
code, inspect the log entries produced by the merge, and use 
the Tools:CheckModel command during your final' review of the 
model. 



Release Phase 



In the Release phase, direct your configuration management 
system to construct a release of all units it controls— require- 
ments;. specifications; plans, controlled units in your model " 
source code, tests, and documentation. 
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Controlled Units 




Using the File:Units:Control command in the File menu's units 
shortcut menu, or the Control button in the Units dialog box 
displayed by the BrowserUnits command, the following model 
components can be controlled: 

• The model kernel-the connective framework for all other 
model subunits. (The model kernel is always a unit.) 

• Any logical package in the model. 

• Any component package in the model. 

• The model's deployment diagram. 

If the Options:Display:UnitAdornment option is enabled, icons 
representing controlled units will be adorned with an octagon 
containing the letter U. s 



Storing Controlled Units 




Controlled units are stored in model files, using specific 
filename extensions 'to designate their contents: 

• Tjie me containing the model kernel utilizes the filename 
;'y-'c' ^extension .nidi. '■r^ r 1 ^** .•■ * ; . ^..y.^' ... •.„.,,.: 

: • ..!?^ 1 ^;P^ c ^ e f v utlllze the filename extension .cat. . 
' '•' Files cbntalWn^^contrbllea uniis^wliich a^ uhe' ; motet's 
* component packages•u^:•0^e;fflehame.exten8i9n^^^ib. 

f ■■■ The -file 1 containing the controlled unit which is the 
./, model's deployment diagram utilizes the" n ipna m e 



extension .pre. 

The file containing controlled units which are the 
property sets for the model utilizes the filename exenslbh 
•prp. This file is indirectly modified throught the Rose 
property.editors. 
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Loading and Unloading Controlled Units 

When a model containing controlled units is first opened, 
Rose presents a dialog. box asking if all units should be 
immediately loaded. If the model is large, or you are planning 
to work on a few specific units, you can reduce resource 
consumption by clicking No and then loading units . 
selectively. 

- : Rose; maintains references between components in unloaded 
* units arid components remaining in the model. These . . 
references are automatically resolved when the; unloaded 
; units are subsequently loaded. . : : > . , 

If the Options:Dlsplay.iJnresolvedReferenceAdornments option is 
selected, icons representing components in unloaded 1 7 

controlled unite; arid icons representing relationships . - 
. involving ari unloaded controlled iiriit are adorned with a 
^small octagon containing 

^Urifts pan be}loade& and uhloadedusi^ 

File:Units:Unload commands respectively^ or rising th^toad arid 
Unload buttons in .the Units dialog box displayed hy the 
Browse:0nifs.c6rnrnarid. An unloaded boritrotied unit ceui be ■ ' - 
d^mand-lgaded by dOuble : clicking.on any icon representing 
it; if the OptionsiConfirmLoadbfUnits option is iselected, a 
; confirmation -dialog box precedes loading. 

The Units dialog box displayed by the BroWserUnits command 
provides a convenient means of determining the 
loaded/unloaded status of every controlled unit in the 
current model. "77 " '7'* "" !: * : ' : 
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Write-Protecting Controlled Units 

Rose prevents you from modifying a write-protected 
controlled unit. Commands that load a controlled unit's 
model file-Fi^Open and File:Units:Load-will write-protect that 
unit if its model file s access control in the platform filesystem 
is read-only. J 

If a controlled unit.is write-protected. the components or 
diagrams it contains are also write-protected unless they are 
nested controlled units. A nested controlled unit maintains 
write-protection independently of its parent. 

Write-protection is enforced by removing the toolbar from 
wnte-protected diagrams, disabling certain menu items when 
the selected icon represents a write-protected component 
... ...and disabling the OK button in the specifications of write- 
protected components: A unit's write-protection status can" be 
examined in the Unite dialog box displayed by the Browse.Units 
.command. ■ ■ ;. 

. Rose's, write-protection mechanism extends the exclusion 
mechanism used by platform configuration management 
Systems to. synchronize the work of multiple users. Model 
/. files representing checked-iri units have read-only access 
; r " : £ cpntroj ln the fUesystem: Rose allows a user to load a - 
« : ; • . cn ecked^in unit. but prevents modification of any component 

; ' ; ; • ■:■ ■ '• ' ordiagrant in the unit.- 'rr >•-=•.." - -. ■ -'w^^W^..-;*, 

- - AWiit's write-protection can be manually enabled or disabled 
.-. usttig the.Rle:lfnteWiltePi^bn.cdi^ahd brihe^^riW'Proted" * 
and Write Enable buttons in the Units dialog box: These : ' 
facilities allow you to load a checked-in unit/ modify it. and 
:• ^ve; the result to a new model file to which you have write 
access^-AlfernativetyHyQu may have load ed - a ehgcK eQ^oW 



unit with the intention of browsing rather than modification- 
manually write -protecting the unit assures that you will not 
inadvertently -change it. the effects of manually changing a 

unit's write protection in this way persist only for the 
duration of your current Rose session, until you re-load the 
unit, or until you open a new model. 
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Note: Manually changing a controlled units wrtte-protectton 
does not alter its model file's access control in the platform fde 
system. If you load a checked-in unit and manually make it 
wnte-enabled. you will not be able to update the units model 
Jile without changing the model file's access control 
Conversely, the File:Save and File:Units:Save commands (and their 
SaveAs variants) will attempt to update a write-protected unit's 
model file: success will depend entirely on the model file's 
access control in the platform Jilesy.stem. 
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To designate a package as a controlled unit: 

1 : Seltct ®n .''icon representing the package. 
. 2. Execute the File:UnitsiConfrpl cominand, 
3. Using the Filename for Unit dialog box, specify the 
name andlocatidn of a modeiflie. wnlch will provide 
persistent storage for this cpntroUed unit.' • 

Rose designates the package as a ^ controUed^tra^. ^ "' 
associates the filename you specified with this unit The 
controlled unit is both loaded and write^enabled after : this 
operation 

To unload a loaded controlled unit: 



1. Select an icon representing the controlled unit. 
.2. Execute the File:Units:Unlqad command. 
Rose unloads the controlled unit, 

to load an unloaded unit: 

1. Select an icon representing the controlled unit. 

2. Execute the File:Units:Load command. 

3. Using the Load From dialog box,, select the model file 
from which to load the controlled unit; this dialog box 
presents the model file currently associated with this 
controlled unit as the default selection. 
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Rose associates the controlled unit with the selected file. If 
the platform filesystem's access control for the selected model 
file was read-only, then the controlled unit is write-protected; 
otherwise, the controlled unit is write-enabled. 

To load a unit which is currently loaded— i.e. to update it with a 
new version: 

1 . Select an icon representing the controlled unit. 

2. Execute the FiIe:Units:Reload command. 

3. Using the Load From dialog box, select the model file 
from which to load the controlled unit; this dialog box 
presents the model file currently associated with this 
controlled unit as the;default selection.. 

Rose associates the controlled unit with the selected file. If 
the platform filesystem's access control for the selected model 
file was read-only, then the controlled unit is write-protected; 
otherwise, the controlled uni t is write-enabled. 

To save a controlled, unit to its associated model file:' 

;l. .Select an icbii ^presenting the controlled unit ' ^l y / • 

This operation will fail if the platform fflesystem's -access 
control settog fbr -the model file is re^^fify^ i " • ; ' ' * * 

To save a contr oiled unit to a 

.1 . Select an icon represe nting th e controlled unit . . 



; 2. Execute the File:Unjts:SaveAs coiniha^cL 

Using the Save To dialog box, select the model file in which to 
save the controlleid unit; this dialog box presents the; model ' 
file currently associated with this controlled unit as- the- 
default selection: 

This operation will faiil if the platform filesystem's access 
control setting for the model file is read-only. 



■l*rmm mam ■ 
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To designate a controlled unit as no longer controlled: 

1 . Select an icon representing the controlled unit. 

2. Execute the Fi!e:Units:Uncontrol command. 

The model file previously associated with the controlled unit 
is not deleted or modified by this command. 

To prevent modification of a write-enabled controlled unit: 

1. Select an icon representing the controlled unit. 

2. Execute the fijerUnrts-WriteProtect command. : •: 

The File:UnitsiWritePrptect command only appears on.the Fi|e:Uhits 
menu if the icoriyott select represents a wrlte-ehabled 
controlled unit This operation has no affect on the platform 
fflesystem's access control setting for the model file 
associated with the seleeted controlled unit. 



T ? ^I^Protected contrblleduntt:, 

r 4vs$ejtect,an;^^ 

2. Execute the File^UnftsrWriteEnable command. 
The Rle:Units:Vl/riteEnable coininariti orily^p^ais 6n the FileiUhlts 
menu if . the icon you select represents a-write-protected 
controlled unit: This operation has rio affect oft the platform 
filesystem's access control , setting for the model file 
-^ss9^^4-witMh^-selecte6 controll ed unit; • . ' 



To invoke a configuration management command with a 
controlled unit as an argument: 

1 . Select an icon representing the controlled -unit. 

2. Execute the File:Units:CM command and select the 

desired, configuration management from the displayed 
submenu. 
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Browsing Controlled Units 
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1 he Units d,alog box. displayed by the Browse:Units command 
allows you to both display and control the status of the model 
kernel, the deployment diagram, the code generation 
properties, each logical package, and each component 
package: 



ww 



i P .™^^?t^- r Component View 
i ^ ik9£?5 , , . C. .Others ■•■'•!• 



.. Pose" < 



J 



Packages; 



Data Services 
\+ User Services. - - 




11 




Thfc- Group option buttons enable you to choose which set of 
model component s are i di spl ayed : . . :, . . , " -W; 



Use case view . Use cases in the model! . - 
• Logical view- All logical packages in themodel. 
Componerit view All component packages in the model. 
Others The model kernel, deployment djagram, 

and code generation properties. 
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The display lists each model component of the kind 
designated by the Group option buttons, using indentation to 
indicate nesting. Each component's state is Indicated by one 
or more letters to the left of its name: Y ° 

The model component is not loaded. 
The model component is write-protected. 
The model component is write-endbled. 
The model component has been modified after it 
was last saved, , 

You^can select a model component by clicking on/its display" 

The Collapse and Expand buttons enable you to control the 
display of jested model .components. . c ° ntTo1 V 1 ? 

32^2* b ° X dlSp ^ ayS ^ name of currenUy-seiected 
model component, . , '". .. c,clcctC9 

If fee select^d model component is a controlled ^hlf^ the ■ ' 
text box displays^p^ame.pf the file .current * 
associated with this controlled unit. : «^5M^y; 

^e comm^d buttons on the .right side of the fts dialog 
box allow you to apply operations equivalent to'tbU to 
F.le:l/n.ts to the selected model component • - ■ ■ 



Comparing Controlled Units 




You can display the differences between two versions of a 
controlled unit by using Rose's Model Differencing tool 
descnbed in the Model Differencing chapter of thilw 



Rose provides the path map mechanism to support parallel 
development by teams of analysts, architects. Zd eZZ „ 

v,^^ CnableS R ° Se to create m °del files whosT - 
embedded pathnames are relative to a user-defined symbol 
Th,s allows Rose to work with models moved or copiedamone 

ZS^Xr h '^r redCfln,, « ^ -tuaiXecto 1 ; 0118 

associated with the user-defined symbol. 
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The path map contains a list of entries; each entry represents 
a mapping between a virtual path symbol and an actual 
pathname. In the example below, the virtual path symbol is 
Sroot, and the actual pathname is c:\user\trw\analyzer: 

root = c:\user\trw\analyzer 

Note: The leading dollar-sign must be omitted in the virtual 
path symbol definition, but must appear in all other usage. 
When a controlled unit is made or saved, each physical 
pathname embedded in its model file will be transformed to a 
virtual pathname by repeating the following steps until no 
replacement is made: 

1- The head of the physical pathname is matched against 
the actual pathnames of the path map entries. If a 
match is found, the head is replaced by the virtual 
, path symbol associated. with the matching actual 
pathname. If more than one match is possible the - 
longest matching actual pathname is replaced by its 
associated virtual path symbol. To be a match, an ■ 
actual pathname must be identical with a prefix of the 
physical pathname, segment by segment; all segments 
must match In their entirety. . 

2. If no match is found for the head of the physical 
r - P a th^.e.:thfi abbye Wchtag algorithm Is applied to 
the physical pathname startlng.with trie second 
segments -.-A 
,: first If that falls, a matehis attempted against the 

third segment: and then theWth ana so on until - 
either a match Is found or ati segments toe physical ' 
pathname have been tested,. When matching Interior - i 
segments of the. physical pathname, any drive name 
preceding the colon in, the actual pathname Is Ignored . 



A .virtual pathname is created by replacing an actual . . 
Pa ^S m T ^ Wfthm a Physical pathname with a Virtual path ■ " 
symbol .Using the, example above, the .physical pathname 
c:\u8er\trw\analyzer\s6urce\par8er.hwouldbe 
transformed to the virtual pathname $root\source\parser.li. 

Rose does not convert physical pathnames in code generation 
properties to virtual pathnames; instead, you make such 
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pathnames virtual by constructing them with a virtual path 
symbol from your path map. 

Virtual path symbols can be applied to four C++ Generator 
properties: model directory, component package directory, 
component spec filename and component body filename Any 
time the path map is edited and you regenerate code the 
virtual symbols in the C++ Generator properties are 
actualized with the current path map entries. 

Traversal attributes may also contain virtual path symbols. 
In this case, the path map\entries are dynamic. The effect of 
editing the path map through the patn map editor is 
, immediately, reflected iri the traversal attribute: For. example 
suppose you have the symbol:' 

project=d:\useir\keri.\rose 

and you generate a class "company" to this directory. The 
path stored in the traversal attribute is: . 
. ^ v $pr6ject\compan r 

Now Suppose you .edit the pafti map using the path map 
editor such that:. •' . ' • 

prQject=d:\user\ken\codegen ... 

If you try to reference "company.h" without saving the model 
or regenerating the code with the C++ .Generator; Rose will 
expect to find, fcompany.h in: 



d:\user\ken\codegeri\company.h 
and log an error. ""' 

When Rose"6pens; loads, imports, browses to source code, 
merges a model file, or uses a pathname specified in a code 
generation property, each virtual pathname is transformed 
back into a physical pathname using the path map 
™ e t ^ anism - If y°ur .ini file contained the following path map 

root = c:\user.\ken.\analyzer ... 

then the virtual pathname $root\source\parser.h would be 
transformed to the physical pathname 
c:\user\ken\analyzer\source\parser.h. 
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Virtual Pathmap Entry Extension 

is relative lo the location of the model (.mdl file) This heln«* 
in referencing files in other directories that retat 23e J^e 
vers.on number as that of the fi.e that is referencing it 
Suppose a model 

; /rose/source/green.ss/sun30xyz.t«rk/rn.rndl - 

references a package 

L /rose/ S ource/red.ss/sun30 X yz.wrk/c.cat, 
. The rose.ini file may. contain. the following path map entry: • 

; ^^ C 5 a ^ ap .^^T 18 «sed to produce a virtual p&to for ' 

virtual path for 

, ■ ;v Mn^ 63 " 801 " Ve ^ iOn0 ^ :6at ^ i " thesarhe tower^ • * 

: . V The virtual.nanie 6f S . . / • - : -: 

Au«;/ S ource/red.ss^ 

; ''is' " \' : ' : • ' ; ' 

:■ . ' . $*cd/c*dat. ' 

SmSr^fn" 8 ^ iS thC addition o' "'"to wildcard a path 
segment. Suppose the rose.ini file contains the path map 

links = &Links/*/../.. 
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This entry causes the pathmap variable links to be 
parameterized with the expansion of ♦. In the example above 
the v,rtual name of c.cat when referenced from m.mdl 

paS as'bffore S(red)/C Cat ' t0 the Same actual 

toads urZh" d ° n f execution of Fi| e=Open command. Rose 
oads its path map from the [Virtual Path . Map] section of 
the current user^s .in! file. Entries should be of the form 

virtual path symbol = actual pathname, for example: 

• •-. [Virtual Path. Map] .... 

' ;"" m ^ 6rk = c :\Project\drs\works.pace . •- O ' • . 

If you changethe fVirtualPath MapJ in your roscini f«e-"'.' 
and are running a Rose release prior to 2.5.20. you must ' 
restart Rose to order ta update its path ma^^^ . . 

running release 2.5.20 or later, Rose updates its path map 
from rose.liii whenever the Open command executed. . 

Integrating with a Contigurati^ 



■ ! l*--^^V -^4^.- 



Integration with the CM system is done through the 
customizable menus mechanism. If there is a customizable 
menu named CM, you will be able to aecess'it through the 
Units Dialog box. A customizable menu file for PVCS is 
supplied with the product. . 

WerecQrnmend that the CM menu beldcated under theiunifar 



submenu of the File menu ; but Rose does not enforce this 

choice. : . - . . . 
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